In <32655078(_dot_)1080412363(_at_)[10(_dot_)12(_dot_)1(_dot_)18]> Greg Connor
<gconnor(_at_)nekodojo(_dot_)org> writes:
So, for the reasons stated above I consider all of these valuable, and
if I have to put them in order of preference it would be:
1> 2821 MAIL FROM (to save bandwidth and provide relief to my mailer)
2> 2822 From: and/or 2822 Sender: (to combat phishing, etc)
These are a CLOSE 1 and 2 for me. I would feel that if we came up
with a solution that handles one and not the other, that it's not a
complete solution. I am willing to set aside one and write a Draft
that only protects one of these, but I feel our work is not done as a
group until we have addressed both, and I would hope that the
mechanisms for both are compatible.
I agree that our work is not done until we address both RFC2821 and
RFC2822 issues. I don't place these two very close together for
pragmatic reasons.
*Because* RFC2821 data is easier to validate, there have been detailed
proposals and proof-of-concept implementations for much longer. (I
posted a proof-of-concept implementation of RFC2821 checking over a
hear ago on ASRG. I used straight DNS to publish, and added a patch
to SpamAssassin to check.)
*Because* there of this longer and more detailed study of RFC2821
validation, there are now designated sender systems that check the
RFC2821 data available now and are actively being deployed.
*Because* of the active deployment of RFC2821 validation systems, I
think the IETF can adopt a standard for such validation much quicker
and have a much bigger immediate impact.
*Because* the IETF can get much more bang for the buck by choosing to
worry about RFC2821 issues first, I think that is what we should do
first.
*Then* the IETF needs to start the harder (but at least as important)
task of validating the RFC2822 data.
If RFC2821 and RFC2822 development were at equal stages, I might well
be tempted to say we should tackle RFC2822 first.
"2821 HELO/EHLO domain" has come up both on SPF-discuss and here. If
there were a solution to detect bad HELO, and to publish enough info
to keep MY domain from being used in a misleading HELO, I would use
it, but I consider it less important. Also, I'm afraid of all the
misconfigured systems out there with bad HELO... They need to be
cleaned up, but I'm not going to push for that being a requirement
because very few people see the HELO, I don't think users would think
of it as a component of "identity".
I agree that there are a lot of bogus HELO domains being sent, but SPF
doesn't force people to clean those up. With SPF, the HELO domain
check fails only if it is not authorized by the domain owner
(e.g. forged). MTAs that send bogus data on the HELO string will
cause the SPF check to return "unknown".
There are other checks in various MTAs that may decide that bogus HELO
data is not acceptable, but that is a separate issue.
-wayne