-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of
Matthew Elvey
Sent: Monday, June 21, 2004 5:12 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] a grand unified theory of MARID (blame me!)
Oh, boy, three posts with misunderstandings. Please forgive my
terseness... Here goes...
Hi, Scott.
It is easy to get off on the wrong tangent...
I think the fundamental misunderstanding on my part was over your original
post saying, "SPF already required that the HELO be valid, so the change
from saying that it MAY be checked to it MUST be checked is not an issue,
with respect to senders having to comply with a new requirement."
I think if you had said "must be valid if it is a FQDN" instead of "must be
valid" then I think I would have be OK with everything. When you say SPF
requires, that sounds to me like you mean SPFv1 (or SPF classic). That's
why I referenced the specs for that. Also, I don't see anything in the
slide show that explicitly adds a requirement that HELO must always be a
FQDN. I think that in the slides, he is assuming the current rule that
says, "...<responsible-sender comes from the HELO argument IF the HELO
argument is a fully qualified domain name".
I suppose this is part of the danger of trying to understand a design just
working at the view graph level...
On 6/20/04 6:50 PM, spf(_at_)kitterman(_dot_)com sent forth electrons to
convey:
HELO strings I get are:
Web host mail server: (HELO {windows machine name})
Web host web mail: no HELO
Other web mail: no HELO
Nonsense. SMTP requires HELO (or EHLO). You're confused.
Poor wording on my part, sorry. What I meant to say was that at the MUA,
the HELO strings I get in the headers are.... My point, now that I've
thought about it, is that since I don't control my mail servers (I pay other
organizations to do that for me), I have no direct way to know HELO, but
that what I get at the MUA level is...
If you're compliant with the currently fielded SPF schema, great. It
requires that the HELO pass in order to be compliant.
Once again, if HELO is a FQDN...
You're reading it quite wrong. Really. It won't break things for you.
Based on what you've said about your situation, for your mail, the EHLO
check will neither pass nor fail, and the old way of validating that you
know and love will kick in and your mail will pass.
Right. And this is the point that I realized (I think) that you were
thinking all along if HELO is a FQDN...
Now that there has been more exchange, it sounds to me like all you are
suggesting in terms of data checking is that the current, "SMTP+SPF
receivers MAY check the HELO argument and MUST check the return-path" should
be changed to "SMTP+SPF receivers MUST check the HELO argument and MUST
check the return-path". If that's what you are proposing, then that's OK
from my perspective. You are right. That wouldn't hurt me a bit as long as
we remember the if HELO is a FQDN part.
What I still don't understand and am concerned about is what you said in
your original post about reputation services:
"Remember, whatever the source for the domain that MARID validates,
blacklists and reputation services will be an integral part of the system.
A domain with a MARID record used in email with malicious forged From: is
gonna get in an RHSBL lickety-split:
If you get word of From: forgery, you're gonna be motivated to do a little
work to get the spammer's domain blacklisted, for example by putting him in
your RHSDRBL (Right Hand Side Distributed RBL), which will stop the forgery
and phishing."
I see from a quick Google search you proposed this same thought on the MARID
list last month.
http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html
I'm still uncertain. Are you saying that an advantage of your plan is that
I'm going to get blacklisted if someone forges my domain name (as they do on
a daily basis now) if I don't get them blacklisted?
Would you please expand upon this idea? It sounds to me like this idea is
very dangerous to me and I want to stay far away... (but perhaps I just
misunderstand the proposal)
Scott K