spf-discuss
[Top] [All Lists]

Re: HELO and Unified

2004-09-14 20:08:09
crossposted from marid ... hoping i won't get smacked by the
chairs for going against the rules for talking about unified.

On Tue, Sep 14, 2004 at 02:14:45PM -0700, Matthew Elvey wrote:
| I have a $50+ spf t-shirt. I'm trying to make MARID's work
| successful. OTOH: A principal of my mail provider (fastmail.fm's
| Jeremy H) is so unhappy with SPF that he's suggesting configurations
| that appear designed to *sabotage* its effectivenness; an IESG
| member's criticism is provided as justification:
| 
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.

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

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 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
check the HELO identity (setting aside questions of protocol
and syntax).  Also mandatory would be the return path,
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 the SUBMITTER and PRA identities would satisfy
 folks who think validating those addresses will help with
 phishing.

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.

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.

| 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.

| 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.


<Prev in Thread] Current Thread [Next in Thread>