Mail application parsing files delivered by sendmail - problems with BCC Recipients
in [Sendmail]
|
Prev: Mail application parsing files delivered by sendmail - problems with BCC Recipients
Next: milter-greylist: greylist: accept() returned invalid socket (Numerical result out of range)
From: Carl Byington on 11 Jun 2008 12:37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 11 Jun 2008 06:19:37 +0000, Per Hedeland wrote: [snip] > Of course the local mailer always gets to see all the (local) recipients, > otherwise it would have a hard time delivering mail to them.:-) The only > purpose of a milter here would be to add them to the headers, which in > principle is quite unnecessary and arguably just a roundabout and more > complex way to collect them than getting them as arguments. I am not sure about lmtp since I have never used it, but a normal mailer with F=m will have $u replaced with all the local users. If we have a virtusertable with something like: a(a)example.com acct b(a)example.com acct a+*@example.com acct+%2 b+*@example.com acct+%2 and email with four recipients of <a(a)example.com> <b(a)example.com> <a+fred(a)example.com> <b+joe(a)example.com> then it might be handy for the local mailer to actually see those recipient envelope values. In the case of a non-lmtp local mailer, at best you will see acct as the user, but the fred and joe tokens will be dropped. If the local mailer needs to see the exact original recipient values, then I think you need a milter to add custom headers for the mailer. Does the lmtp conversation between sendmail and the local mailer pass the original recipients to the mailer, or does it pass something like rcpt to:<acct(a)my-host-name>? RFC2033 is unclear on that. In the above case with four original recipients, how many recipients does an lmtp local mailer see? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFIT/82L6j7milTFsERArHqAJ0WDgVgr9k9jDNqKJkkI2YuTxMJmQCfVwcZ awmGUdSzb02KzkJ9u5CN4X0= =C9pj -----END PGP SIGNATURE-----
From: Per Hedeland on 11 Jun 2008 18:53
In article <pan.2008.06.11.16.37.45.462516(a)five-ten-sg.com> Carl Byington <carl(a)five-ten-sg.com> writes: > >On Wed, 11 Jun 2008 06:19:37 +0000, Per Hedeland wrote: > >[snip] >> Of course the local mailer always gets to see all the (local) recipients, >> otherwise it would have a hard time delivering mail to them.:-) The only >> purpose of a milter here would be to add them to the headers, which in >> principle is quite unnecessary and arguably just a roundabout and more >> complex way to collect them than getting them as arguments. > >I am not sure about lmtp since I have never used it, but a normal mailer >with F=m will have $u replaced with all the local users. Yes, it's analoguous for LMTP - there's no $u, but all the local users will be passed in the same LMTP session (or not, if F=m isn't used). > If we have a >virtusertable with something like: > >a(a)example.com acct >b(a)example.com acct >a+*@example.com acct+%2 >b+*@example.com acct+%2 > >and email with four recipients of ><a(a)example.com> ><b(a)example.com> ><a+fred(a)example.com> ><b+joe(a)example.com> > >then it might be handy for the local mailer to actually see those >recipient envelope values. In the case of a non-lmtp local mailer, at best >you will see acct as the user, but the fred and joe tokens will be >dropped. That depends on the local mailer definition - special magic in the rules that resolve to the local mailer passes the "detail" part as $h to the mailer. A "simple" local mailer definition doesn't have $h, so it does indeed get dropped - but if you use e.g. FEATURE(`local_procmail'), you get an Argv of 'procmail -Y -a $h -d $u', and the "detail" becomes available as $1 in your ~/.procmailrc. > If the local mailer needs to see the exact original recipient >values, then I think you need a milter to add custom headers for the >mailer. Yes, good point, but the OP mentioned neither virtusertable translations like the above nor a need to see the original addresses. On the contrary he had been experimenting with header definitions including $u, and only noted the problem that it only worked for a single recipient. >Does the lmtp conversation between sendmail and the local mailer pass the >original recipients to the mailer, or does it pass something like rcpt >to:<acct(a)my-host-name>? RFC2033 is unclear on that. It's outside the scope of the RFC, but the sendmail functionality is a plain (well maybe not so plain but...) address translation - if it didn't give the translated address to the destination mailer, whether remote, local/non-lmtp, or local/lmtp, it would just be broken. I'm not sure exactly what it uses for the domain-part though (if anything) - and presumably the $h will be dropped in this case too, since there's no sensible way to pass it to the LMTP mailer. >In the above case with four original recipients, how many recipients does >an lmtp local mailer see? Good question:-) - since duplicate address elimination happens before resolution to a mailer, acct, acct+fred, and acct+joe are considered different, even though they all end up as just 'acct' for $u. A naive guess would be that it will see three identical 'acct' recipients, but that seems too stupid... - maybe someone that uses "plussed addresses" with LMTP can comment, I don't and can't be bothered to test it. --Per Hedeland per(a)hedeland.org |