--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<value>" 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: <whomever> 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--
(text/plain)