In <00c201c56110$708ff220$6c62fea9(_at_)ibmrkydk2ufvdd> "John Glube"
<jbglube(_at_)sympatico(_dot_)ca> writes:
In <017801c55fd2$5a348750$6c62fea9(_at_)ibmrkydk2ufvdd> "John
Glube" <jbglube(_at_)sympatico(_dot_)ca> writes:
<snip>
|> * Use SPF to both authenticate the mail stream and
|>validate the return path. I don't agree with the
|>present approach of expanding SPF to cover EHELO/HELO
|>checks, simply because SPF was designed to focus on the
|>SMTP mail from authentication.
|
|SPF had checks against the HELO domain from the very first
|spec released almost 2 years ago. All that has changed is
|that over a year ago, this HELO check was said to be ok to
|do separately, and more recently this check has been
|changed to RECOMMENDED.
|
|There is very little new here, and no real "expansion of
|SPF".
Don't compound the design errors by mixing apples and
oranges. The HELO and SMTP MAIL FROM serve different
purposes. As I understand it, the HELO address identifies
the server making contact. The SMTP MAIL FROM address is
the address to which delivery status notices are sent. Each
identity serves a different purpose.
Yes, each identity serves a different purpose, but both identities use
the same DNS system. Similarly, I don't think it is out of line for
both identities to use the same policy language (SPF).
For this reason, each identity deserves its own design
approach, which requires a separate protocol so allowing
focused effort being placed on the problems and
difficulties surrounding the use of that identity for the
purpose of email authentication, given the complexity of
the email infrastructure.
I think there is a trade-off between having different mechanisms that
are tuned to each job, and having to learn only one technique that can
be used several places, but is not optimal.
It is kind of like which is the best to have: boxed-end wrenches,
open-end wrenches, cresent wrenches or a socket set with extenders?
Well, I think it depends on the situation. The flexibility of SPF to
do both HELO and MAIL FROM checking is nice, and in my very humble
opinion ;-) we don't need something as specialized as both SPF and
CSV.
|Well, I wish the best of luck to the CSV folks. I confess
|that I've been way behind on email for several months now.
|Could you give a brief description about how the CSV folks
|are progressing? Lots of good news on their mailing list
|about new implementations and deployment?
There is a fable about the tortoise and the hare. The hare
in all its excitement lost the race. People need to bear
that fable in mind, although email authentication is not a
race. Rather it is serious business and protocol designers
need to ensure all the edge cases are considered before
running off and saying this is the way.
Well, the fable about the tortoise and the hare involved the hare
falling asleep and not moving for a long time while the tortoise
plugged along. I just checked the MASS and CLEAR mailing lists, and
there has been almost no traffic for a long time. Part of the reason
why I wasn't posting here very much was due to the ever increasing
demands on the T-FWL. It appears that CSV has far less deployment now
than SPF HELO checking had back in 2003.
So, yeah, please keep that fable in mind. SPF is moving forward, even
if it isn't always sprinting.
|>The whole underlying premise of the SPF design was to
|>ensure that "bounces" went to the right place. How was this
|>to be achieved?
|I disagree that blocking bounces was the "whole underlying
|premise of SPF". That was a hot button for some people,
|but not everyone. Personally, I think the 2821.MAILFROM
|identity is just the most useful identity to validate in
|the current state of email.
|
|Unlike the 2821.HELO identity, the 2821.MAILFROM identity
|is actually used for something and so it is much more
|likely to be correct.
|
|Unlike things like the 2822.From: identity, the
|2821.MAILFROM identity is available at SMTP time. The
|2822.From: identity can also be a list of addresses and it
|has interactions with the 2822.Sender: identity that are
|not aways well understood by everyone.
Given this rational and analysis, why clutter up the design
by recommending that people check the 2821.HELO identity as
well as the 2821.MAIL FROM identity?
Or is the real agenda a political goal, to establish SPF as
the record of choice for checking both the 2821.HELO
identity and the 2821.MAIL FROM identity and so outflank
any perceived threat from designs which focus solely on
checking the 2821.HELO identity?
Uh, SPF HELO checking was being done in 2003, long before the CSV
folks even started. If you want to get into conspiracy theories, I
think it is far more reasonable to ask "Why was CSV created when SPF
HELO checking already existed?"
My second rant in two days. I must stop this.
Naw, please don't stop. I really appreciate your input, even if I
don't agree with it.
-wayne