Ryan Malayter wrote:
Since we won't be able to authenticate 2822.from reliably for the
foreseeable future, why not do away with it entirely by slapping
2821.from in there?
I cannot believe you would even suggest this with a straight face.
So I ask again - and please provide some examples this time if you
choose to respond - what critical email delivery functions would
rewriting the 2822.from at edge MTAs break? The 2822.from header is
only an "informational" header, and has no effect on message delivery,
right?
Mixing layers is almost always a very bad idea; this being no exception. Do
you really want a few examples? The ol' mailing list, again. Do you really
think I am subscribed to this list with my, almost constantly differing, SRS
address? And how will the mailing list software recognize me? It could not;
unless it happened to catch my email at the SMTP dialogue layer (which is
rather unlikely; far more likely is that that it will be delivered to some
LDA, or alias-expanded script, which handles the mailing list; read: at an
entirely different layer).
To make things a bit worse, do you really want this email, from me, to have
the "pretty name" (btw, what a very American way of putting things, lol) be
that of the mailing list envelope-from? Great way to tell it came from me,
then!
I know mailing lists and forwarders will not show the original
sender of the message. But the 2822.reply-to header can
remain intact, so that's not a huge problem, is it?
What do you mean, "intact"? You make it sound like it is always there.
Basically, you would then also have to rewrite/add the Reply-To: header to
the original pretty 2822 From: address. But that is not for you to set;
because the sender has typically added a Reply-To: for *precisely* this
reason: to have a reply go elsewhere, instead of to the 2822 From: address
(where replies would normally go).
So, let's don't, and say we did.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx