Am 30. Jul, 2001 schwäzte Nick Estes so:
> -----pgpenvelope processed message-----
>
> > Good thing I was playing with sendmail all this morning... =op
> > Coincidentially, I was looking for exactly that functionality. The option
> > that sounds like what you're looking for is NoRecipientAction
> > ("O NoRecipientAction=<value>" in the sendmail.cf file).
>
> 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 sendmail
:).
> 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 seem
> that when I'm actually interested in the header, it conveiniantly forgets
> to put in the received for part. (I suspect that it's a conspiracy) (-=
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 just
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.
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 just
copy Envelope-to: headers to X-Envelope-to: headers ( or something similar )
or better yet, use X-Envelope-to: headers to build the chain.
For example, say a piece of mail is sent to
LuftHans@example.com, which gets
forwarded to
LuftHans@anotherexample.com, then to
LuftHans@ex.com, then
finally to
LuftHans@Beispiel.com.
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, however,
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:
X-Envelope-to:
LuftHans@example.com,
LuftHans@anotherexample.com,
LuftHans@ex.com,
LuftHans@Beispiel.com
The commas could easily be -> or => if that's legal in mail headers.
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 longer
valid, e.g. it goes straight from ex.com to NicksToys.com, then ex.com would
drop the X-Envelope-to: chain for Nick@ from the message.
What if, however, both were final boxes at Beispiel.com? Well, at the final
delivery to
LuftHans@Beispiel.com Nick@Beispiel.com would not be valid, so
would be dropped before hitting the LuftHans mailbox ( or whatever forwarder
might be in there ).
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 :).
ciao,
der.hans
[1] Also found the following in exim.conf, envelope_to_add = true.
--
#
der.hans@LuftHans.com home.pages.de/~lufthans/
www.DevelopOnline.com
# I chose to use the kernel sources as my documentation. ;-)
# -- Kevin Buettner
(text/plain)