spf-discuss
[Top] [All Lists]

Re: a grand unified theory of MARID (blame me!)

2004-06-21 02:12:05
Oh, boy, three posts with misunderstandings. Please forgive my terseness... Here goes...
Hi, Scott.

On 6/20/04 6:50 PM, spf(_at_)kitterman(_dot_)com sent forth electrons to convey:

-----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: Sunday, June 20, 2004 8:10 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] a grand unified theory of MARID (blame me!)


Hello from a regular MARID poster!

Meng's latest SPF plan (in which he has borrowed my idea of CSV
semantics using SPF records) was influenced by, among other things, a
group of us pushing strongly for HELO to always be checked.  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.  Meng's latest SPF
plan, does not require senders to comply with a new requirement at all
(vs. the old SPF).
snip
From the lastest working draft posted on the SPF web site:
http://spf.pobox.com/spf-draft-200405.txt...

Yeah, dated May.  It's now late June.  Please see
http://spf.pobox.com/slides/unified%20spf/0428.html

That slide is from the slideshow at
http://spf.pobox.com/slides/unified%20spf/index.html
that Meng pointed me to.


I read "may provide" as meaning that the smtp client may provide, not must.
Yeah, Meng is changing things.  See his post that started this thread!

snip

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.

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?  If this is correct and that becomes
the plan, there is no way to get me to participate.  I'd be worse off than
an I am now.  All I get now is a bunch of bounce messages that I have to
delete.

snip

MTA admins just need to ensure that they are sending appropriate HELO
strings, which nearly all already are, and create DNS records. Wow,
that's not a lot of systems that need touching, relatively speaking!
(Around 2 orders of magnitude fewer than SPF+SRS).

I don't know about your "nearly all".  I can send e-mail from my domain 5
different ways using Outlook 2000, webmail, and Snappermail (Palm OS).  The
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.

Comcast SMTP:  (HELO {windows machine name})
Web host mail server from palm device: (HELO ?{dhcp supplied IP address}?)
I am compliant with the currently fielded SPF schema (and with the merged
SPF too) because "SMTP+SPF receivers MAY check the HELO argument and MUST
check the return-path".  With your plan it appears to me that I am out of
luck until 4 different servers get upgraded.  Your nearly all appears to be
none for me.
If you're compliant with the currently fielded SPF schema, great. It requires that the HELO pass in order to be compliant. It seems you're not as compliant as you think you are. Or you're using a smarthost that sends a valid HELO. It only matters that the SMTP clients sending to untrusted hosts have SPF records, valid HELOs, etc. All the systems above are normally going to be connecting to hosts that trust them, typically with SMTP AUTH.
This is shown at http://spf.pobox.com/slides/unified%20spf/0440.html

snip
In
fact, there's an argument to be made that with HELO, SPF will do a
better job preventing the forgery; it goes like this:
Because it will have a much lower implementation cost, it will get
implemented sooner. After broad adoption, this will be tough: the forger
will have just two major options: use an un-blacklisted domain he runs
on an MTA he runs (losing anonymity), or free rein over these things run
by someone who controls them well enough to keep the domain off BLs (an
increasingly hard thing to find).

OK.  I've already published SPFv1 records.  It appears to be impossible for
me to develop a record that is consistent with your proposal.  I find it
unlikely that I will be able to accomplish your proposal faster than I could
the original SPF approach.
snip

I welcome your questions and comments.

=-=-=-=-=-=-=
Either I am reading this proposal and my e-mail headers completely wrong (I
admit this is a possibility, I am primarily an e-mail user, not an e-mail
expert) or this would be a disaster for me.
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.

Scott K