Ryan Malayter wrote:
[Mark]
Mixing layers is almost always a very bad idea; this being no
exception.
How will we ever validate 2822.from without checking it at SMTP time,
knowing what IP it came from?
I never said we should not check 2822 From: at SMTP level; we should. I said
mixing layers is a bad idea -- in this case, substituting the 2822 From: for
the envelope-from. Because the 2822 From: has a different function than the
envelope-from.
Or do you propose relying on a crypto solution like DomainKeys for
2822 authentication (which wouldn't need IP information)?
Since all headers are part of the DATA phase, unless you cryptographically
sign that data, the content remains unreliable. The best you can say about
the headers, is that parts of them have to appear in a certain format; that
is all.
You could also do SPF checks on the 2822 From: entity. But I only say this
to underline my point about mixing layers: it would break horribly for
mailing lists, as SPF checks are, correctly, done against the envelope-from
of the mailing list sender (which check out), whereas such a check against
the 2822 From: would fail, of course. Not a good idea, therefore.
Truth is, nobody has really come up with a satisfactory solution for making
the DATA reliable. Digitial signatures often have the disadvantage of being
too rigid (e.g. the slightest variation tends to break things), and I have
yet to see a good in-between solution.
Anyway, with the current situation, I can easily forge messages to the
list that appear to be from you, because 2822.from is unauthenticated.
That does not make your "solution" better. What you are effectively saying,
is to do away with 2822 From: altogether (in the sense that it would just be
the same as the envelope-from). I, for one, will not sign off on that.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx