--Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2001 at 01:05:32AM -0700, der.hans wrote: > Am 30. Jul, 2001 schw=E4zte Nick Estes so: >=20 > > -----pgpenvelope processed message----- > >=20 > > > Good thing I was playing with sendmail all this morning... =3Dop > > > Coincidentially, I was looking for exactly that functionality. The op= tion > > > that sounds like what you're looking for is NoRecipientAction > > > ("O NoRecipientAction=3D" in the sendmail.cf file). > >=20 > > Thanks! This option should help, I'll have to play with it and see where > > along the translation path it figures out the address. > > Hmmm. That looks like the wrong way to do things ( even if it is in sendm= ail > :). LOL Tell me about it. =3Dop The manuals for the configuration files read like an INTERCAL language specification. Still, I searched through the durn thing at least 15 times looking for some other way of doing it (you'd think that sendmail would be intelligent and grab the MAIL To: command from the SMTP system and use that as the To: header when the MTA forgets to add a To: header in the actual envelope) but alas, this seems to be the only simple way -- save for rewriting the individual rulesets for handling mail. =3Do/ Quite frankly, I'm thinking about moving to Qmail -- sendmail's too much of a headache to maintain. > > Unfortunatly, the received header isn't always terribly reliable. If I > > pick a random message in my mailbox (like this one), and look at the > > received header, it will give me the right answer; however, it would se= em > > that when I'm actually interested in the header, it conveiniantly forge= ts > > to put in the received for part. (I suspect that it's a conspiracy) (-= =3D >=20 > Never noticed that some of my messages don't have recieved fors in them. > Only a small percentage of the SPAM I just browsed through, though ( as an > aside, I didn't realize the really exciting stuff I've been neglecting to > read, I think I'm gonna stop reading PLUG and debian mailing lists and ju= st > concentrate on that wonderful SPAM :). ( Back on topic ... ) Most of the > mail had recieved for entries that let me know which of my multitude of > email addies the mail was going to. This probably only works, though, > because I'm really only working one domain. Multiple domains and rewrite > tables probably won't work as well. >=20 > I did notice, however, that exim is leaving the Envelope-to: header intact > for me[1]. I would think the correct way to do this would be to either ju= st > copy Envelope-to: headers to X-Envelope-to: headers ( or something simila= r ) > or better yet, use X-Envelope-to: headers to build the chain. >=20 > For example, say a piece of mail is sent to LuftHans@example.com, which g= ets > forwarded to LuftHans@anotherexample.com, then to LuftHans@ex.com, then > finally to LuftHans@Beispiel.com. >=20 > That gives us Envelope-to: LuftHans@Beispiel.com when the message hits the > final mailbox. Doesn't tell us the path it went through. Presuming, howev= er, > that I run all of the above mail daemons, I could track this. Say the > message was actually sent To: LuftHans@example.com, then example.com will > have and Envelope-to: LuftHans@example.com. It could set X-Envelope-to: to > LuftHans@example.com. Now when anotherexample.com gets the message, it > appends the new Envelope-to: addy such that it is now X-Envelope-to: > LuftHans@example.com, LuftHans@anotherexample.com. At the final resting > place that would become: >=20 > X-Envelope-to: LuftHans@example.com, LuftHans@anotherexample.com, > LuftHans@ex.com, LuftHans@Beispiel.com >=20 > The commas could easily be -> or =3D> if that's legal in mail headers. >=20 > What happens, now, if we have Envelope-to: LuftHans@example.com, > Nick@example.com? In the end it's probably better for LuftHans not to be > able to track that Nick was in there and vice versa ( as this would affect > things other than SPAM, e.g. legitimate uses of BCC: ). OK, now we inject > two X-Envelope-to: headers. One for each. At the point that one is no lon= ger > valid, e.g. it goes straight from ex.com to NicksToys.com, then ex.com wo= uld > drop the X-Envelope-to: chain for Nick@ from the message. >=20 > What if, however, both were final boxes at Beispiel.com? Well, at the fin= al > delivery to LuftHans@Beispiel.com Nick@Beispiel.com would not be valid, so > would be dropped before hitting the LuftHans mailbox ( or whatever forwar= der > might be in there ). >=20 > Granted, I'm no mail expert and I don't know how to implement any of what > I've just described, but I will be changing my procmail recipes to trigger > off of Envelope-to: headers :). Whoo... Quite a specification there. You might want to write that up in a formal RFC so that (maybe) somebody can implement it -- I'd do it, but with a lack of knowledge of how most MTAs work, etc, I think I'll leave it to the guys with more experience. =3Dop -- Mondoshawan > ciao, >=20 > der.hans >=20 > [1] Also found the following in exim.conf, envelope_to_add =3D true. > --=20 > # der.hans@LuftHans.com home.pages.de/~lufthans/ www.DevelopOnline.com > # I chose to use the kernel sources as my documentation. ;-) > # -- Kevin Buettner >=20 > ________________________________________________ > See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't p= ost to the list quickly and you use Netscape to write mail. >=20 > PLUG-discuss mailing list - PLUG-discuss@lists.PLUG.phoenix.az.us > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Zsh9Yp5mUsPGjjwRAqOrAJ9USaSfjPep/5ExrBJrPnMXrhc5vACeLBHI 0kZX1+MB8gfmnzQvsTKITJk= =onTs -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z--