On 9/14/2004 7:41 PM, Meng Weng Wong sent forth electrons to convey:
On Tue, Sep 14, 2004 at 02:14:45PM -0700, Matthew Elvey wrote:
|...
|
http://www.emailaddresses.com/forum/showthread.php?threadid=22341&highlight=spf
The unhappiness there seems to be with SPF Classic, and is
remedied by Unified. I would like to take this opportunity
to expand on some ideas for the working group's
consideration.
| It's certainly been explained many times, on-list, by many people. I
| see strong confirmation that HELO scope would be useful, and an
| appropriate change to make. I see little reasoned opposition to a A
| HELO scope.
I now agree that checking HELO can be very useful, as it
satisfies the ESP->ISP whitelisting requirement nicely, and
also has the benefit of making life easier for forwarders
who would then be able to skip SRS.
I don't understand why you always talk about HELO checks only in
combination with whitelisting.
Any domain relevant for a MARID record check is a good candidate for
checking whitelists and blacklists (A&R services)...
Certainly, it's particularly urgent that forwarders get whitelisted if
an SPF check on MAIL FROM will otherwise be done because it will fail.
But it makes sense, IMO, for any domain used in HELO that has a good
reputation (and is authorized for use by the MTA, of course) to result
in a 'pass'.
BTW, is there a definition of ESP? As I understand it, fastmail.fm and
hotmail.com, for example, aren't what you'd call ESPs. (I'm not sure
what I would call them.) Is ESP a euphamism for Bulk Mailer? (E.g. that
sends anything from bank statements, and bank marketing spam, to
mainsleaze) I'd say it's http://www.espcoalition.org/members.php and
competitors.
The ESP->ISP whitelisting requirement can be satisfied by
way of a private arrangement between the parties involved,
so strictly speaking we do not need to standardize that
convention.
But if we want to remove the SRS requirement for forwarders
without weakening protection for the other identities, we
would have to require either one of two things:
1) that we make HELO checking mandatory for receivers, and
that receivers be easily capable of whitelisting
forwarding systems by that identity, or
I don't see the necessity of the second half of that sentence. You
assume receivers will insource whitelist maintenance, and I see no
reason for making that assumption. I'd say "1) that we make HELO
checking mandatory for receivers, and easy for A&R service checks to be
made on the authorized domain."
2) that we make SUBMITTER mandatory for forwarding senders
and receivers.
Of course, we would also specify that a positive result
(where auth+policy both pass) would override failures
elsewhere in the system.
Note that the trusted-forwarder.org checking in most SPF
Classic implementations essentially sneaks the first benefit
into the system, by way of a PTR identity.
That's good, but the full A&R stuff should be in there too.
That first rule
changes that to a HELO identity, but provides the same
benefit.
If consensus does not oppose HELO checking, then a
"unification" draft could require that receivers always
IIRC, a unification draft was started. Right?
Should this new unification draft be called SPF3? SenderID2? USPF? What
would you prefer it be called?
check the HELO identity (setting aside questions of protocol
and syntax).
Also mandatory would be the return path,
Mandatory? My reading of the Unified stuff (e.g. the .ppt slideshow)
was that if HELO resulted in a pass (i.e. a whitelist or strong A&R
check) then no further checks would be made.
Also what's mandatory? a DNS record supporting it? It always being
tested and passing?
SUBMITTER (when checking before DATA), and PRA (when
checking after DATA) identities. This choice of identities
is justified by the following argument:
Making HELO-checking mandatory should satisfy folks who want
to get their MTAs whitelisted easily. This includes ESPs
and forwarders.
Checking the return path would satisfy folks who want to
limit unauthorized use of their domain names in the return
path.
Checking this would make sense if previous tests hadn't resulted in a
pass and/or the retrn path was going to be used - a bounce was going to
be induced/sent to it.
Checking the SUBMITTER and PRA identities would satisfy
folks who think validating those addresses will help with
phishing.
You've gotta drop PRA. You'll never get a majority, let alone rough
consensus, for something 'till you do; someone else's draft will proceed.
If folks agree, it might be useful to standardize that set
of identities in the "must check" list.
The essential difference between the HELO identity and an IP
address is that it's easier for a receiver to whitelist
*.mta.example.com and not worry about IPs. This is one big
driver in the ESP->ISP whitelisting relationship.
It's also easier to blacklist a domain than an IP!
The essential difference between the HELO identity and the
PTR, both of which are (nominally) hostnames, is that it's
easier for senders in some parts of the world to set up
forward-lookup (domain -> SPF/TXT/A -> ip) mappings than
reverse-lookup (ip -> PTR -> domain) mappings due to PTR
delegation brokenness. Also we have been asked by the DNS
people to refrain from putting additional load on the PTR
system if possible.
Oh, I missed that request. A pointer and/or quote would be appreciated
if it wasn't made on this list.
| Some reasons the market may go with the HELO scope instead of the others
| (assuming this leave-it-to-the-market proposal flies) are that it has
| the advantages of not using restricted IPR, doesn't break
| forwarding/mail-list/backup mx operations, and doesn't require end-user
| action to implement.
Agreed, many of the CSV proponents have made these arguments
also.
Yup - I was surprised HELO wasn't in SenderID; I had expected it to be
more, not less prominent than it was in SFP.
| Also, the way that Accredidation and Reputation services are to be used
| is essential. It belongs in a BCP, which should specify BFP (Best
| Future Practice) for how various tests should be interpreted and acted
| upon. SPF claims to address the spam problem (according to text that
| was on the spf.pobox.com home page) so the Accredidation and Reputation
| services that are a necessary component to this solution must be
| specified. An incomplete spec that lacks these things has no business
| aspiring to be an Internet Standard. How can a spec that is grossly
| incomplete be properly reviewed by us or the IESG? It can't!
| E.g. John Leslie is quite confused about how A&R might work, or I am, as
| mentioned above.
Yes, a Unified proposal would need to discuss at least
reputation, at least in terms of local policy. A spec for
Accreditation would also be useful.
As we are getting off topic for MARID, which is focused on
Sender ID at the moment, I suggest we discuss Unified
further in another forum, and report back with our findings
at a more appropriate time.
IMO, this is the right place/time to discuss HELO and Unified.
CSV/MPR and Unified are the leading contenders now.