Hello,
the postfix' sendmail -bv option has different usage than sendmail's -bv: -bv Verify names only - do not try to collect or deliver a message. Verify mode is normally used for validating users or mailing lists. # sendmail -bv [hidden email] [hidden email]... deliverable: mailer local, user xxx The "sendmail -bv" can be used by spamass-milter to resolve destination user and to use that users' spamassassin preferences: -x Pass the recipient address through sendmail -bv, which will per‐ form virtusertable and alias expansion. The resulting username is then passed to spamc. Requires the -u flag. The spamass-mil‐ ter configuration process does its best to find sendmail, but it is possible to override this compiled-in setting via the -- spamc flags ... Pass all remaining options to spamc. This allows you to connect to a remote spamd with -d or -p. Anyone's got an idea how to get this with postfix? Postfix's "sendmail -bv" sends real mail to recipient. only expanding virtual aliases should be fine. -- Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. |
Matus UHLAR - fantomas:
> Hello, > > the postfix' sendmail -bv option has different usage than sendmail's -bv: > > -bv Verify names only - do not try to collect or deliver a message. > Verify mode is normally used for validating users or mailing > lists. > > # sendmail -bv [hidden email] > [hidden email]... deliverable: mailer local, user xxx With Postfix, that is funndamentally not possible, because deliveries happen asynchronously in the background. I'll resist the temptation to harp on the security holes that I elininated this way. OK, one: real Sendmail would import a hostile LD_LIBRARY_PATH or LD_PRELOAD setting from a local attacker, and would use that setting while it executed delivery to "|commmand" in .forward files. This allowed a local attacker to execute commands with the privileges of the recipient. > The "sendmail -bv" can be used by spamass-milter to resolve destination > user and to use that users' spamassassin preferences: > > -x Pass the recipient address through sendmail -bv, which will per? > form virtusertable and alias expansion. The resulting username > is then passed to spamc. Requires the -u flag. The spamass-mil? > ter configuration process does its best to find sendmail, but it > is possible to override this compiled-in setting via the Well that isn't going to work with Postfix. The sendmail emulation can only go so far; if you want 100%, use real sendmail. > only expanding virtual aliases should be fine. The following: (postmap -q [hidden email] maptype:mapname || postmap -q @example.com) will exit with status 0 (success) if a match was found. It'll take more code to handle the third form: stripping an address extension. Let me know if you need help. Wietse |
Wietse Venema:
> > The "sendmail -bv" can be used by spamass-milter to resolve destination > > user and to use that users' spamassassin preferences: > > > > -x Pass the recipient address through sendmail -bv, which will per? > > form virtusertable and alias expansion. The resulting username > > is then passed to spamc. Requires the -u flag. The spamass-mil? > > ter configuration process does its best to find sendmail, but it > > is possible to override this compiled-in setting via the > > Well that isn't going to work with Postfix. The sendmail emulation > can only go so far; if you want 100%, use real sendmail. > > > only expanding virtual aliases should be fine. > > The following: > > (postmap -q [hidden email] maptype:mapname || > postmap -q @example.com) > > will exit with status 0 (success) if a match was found. > > It'll take more code to handle the third form: stripping an > address extension. Let me know if you need help. In the course of Postfix 3.x development I made the table lookup sequences configurable internally, but haven't found the time to expose that as main.cf settings. For that, the underlying code needs to make fewer assumptions about how it will be used. The idea is that given a full email address, postmap -q [hidden email] -m virtual_alias maptype:mapname would query the table with the same sequence of full and partial addresses as virtual_alias_maps, and thereby take some of the mystery out of how Postfix works. I suppose it might be educational if postmap can make its generated queries visible. Wietse |
reviving old thread (hopefully I can get here now)
>> > The "sendmail -bv" can be used by spamass-milter to resolve destination >> > user and to use that users' spamassassin preferences: >> > >> > -x Pass the recipient address through sendmail -bv, which will per? >> > form virtusertable and alias expansion. The resulting username >> > is then passed to spamc. Requires the -u flag. The spamass-mil? >> > ter configuration process does its best to find sendmail, but it >> > is possible to override this compiled-in setting via the >> > only expanding virtual aliases should be fine. >Wietse Venema: >> The following: >> >> (postmap -q [hidden email] maptype:mapname || >> postmap -q @example.com) >> >> will exit with status 0 (success) if a match was found. >> >> It'll take more code to handle the third form: stripping an >> address extension. Let me know if you need help. On 28.08.20 14:30, Wietse Venema wrote: >In the course of Postfix 3.x development I made the table lookup >sequences configurable internally, but haven't found the time to >expose that as main.cf settings. For that, the underlying code needs >to make fewer assumptions about how it will be used. > >The idea is that given a full email address, > > postmap -q [hidden email] -m virtual_alias maptype:mapname -m enables mime parsing, perhaps you meant a new option? >would query the table with the same sequence of full and partial >addresses as virtual_alias_maps, and thereby take some of the mystery >out of how Postfix works. I suppose it might be educational if postmap >can make its generated queries visible. That would be great, but IIUC, it's not available now. I could probably do it using postconf to get virtual_alias_maps and "postmap -q" to expand aliases. But I'd like to know order in which they are expanded by postfix: - do I need to query repeatedly, until virtual_alias_expansion_limit is reached? (postmap -q returns first query) - how to repeat queries, if multiple lookup maps are used? Repeat first map until no expansions are made or cycle through all maps with all lookups? thanks. -- Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory. |
Matus UHLAR - fantomas:
> I could probably do it using postconf to get virtual_alias_maps and > "postmap -q" to expand aliases. But I'd like to know order in which they are > expanded by postfix: > > - do I need to query repeatedly, until virtual_alias_expansion_limit is > reached? > (postmap -q returns first query) > > - how to repeat queries, if multiple lookup maps are used? > Repeat first map until no expansions are made or cycle through all maps > with all lookups? Postfix code works as follows: for each query pattern # user@domain, @domain, localpart, ... for each map in mumble_maps search the map for the query pattern I left out the code that takes a search result and does something depending on the query pattern that was matched (user@domain, @domain, localpart, ...). The reason for this arrangement of the two loops is that the query patterns were generated by hand-crafted code, one iteration at a time. We could change that with a data-driven approach, but it would be incompatible with existing behavior. Wietse |
Free forum by Nabble | Edit this page |