-----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
2.2.1 Subject of SPF testing
In an SMTP transaction, an SMTP client may provide FQDNs in the HELO
argument and in the MAIL FROM return-path. SMTP+SPF receivers MAY
check the HELO argument and MUST check the return-path. A single
SMTP transaction may therefore trigger one or two SPF queries.
Accordingly, the <responsible-sender> may be drawn from the HELO
argument or from the "MAIL FROM" return-path. This document
sometimes refers to the <responsible-sender> as the "envelope
sender".
I read "may provide" as meaning that the smtp client may provide, not must.
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
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.
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.
Scott K