Re: [spf-discuss] Using SPF op=helo for HELO Authorization

At 01:16 PM 1/29/2007 -0500, Stuart D. Gathman wrote:
> On Mon, 29 Jan 2007, David MacQuigg wrote:
>
> > OK, I found the draft (draft-ellermann-spf-options-01).  Doesn't look like
> > op=helo will do what we need, however.  Section 3.2 of the draft refers to
> > "the FQDN given in a HELO command", and I assume this means the complete
> > hostname, not just the domain name which we are using as the transmitter's
> > ID.  If I understand it correctly, this option offers basically the same
>
> It means the HELO name.  It can be any FQDN you wish that resolves to
> an IP.  You can use the same name for multiple hosts, just list all
> the IPs authorized to use that name in the SPF record.  (You can also
> list them via multiple A records for the name.)
>
> > functionality as CSV, requiring an authentication record for each and 
> every
> > host, which we can't expect domain owners to do.
>
> You need an authentication record for each and every name you
> want to authenticate with SPF, HELO or otherwise.
So if we want just one record for rr.com, we will need to convince them to say
HELO rr.com
and not include the complete hostname, in violation of RFC compliance.

> There was a proposal for "zone cuts" for SPF a while back to provide
> default SPF records and reduce the number of records to be published
> in some cases.   But it really doesn't save publishers any work, and made
> checking more complicated.  For instance, a Bind zonefile macro works
> just as well to save typing.
My concern is not so much the work large domain owners might have in 
maintaining all these records, but our ability to consolidate identity and 
reputation at a sensible level.
There might be a way to do this in SPF without "zone cuts" or "tree 
walking".  Of course, it would have been nice if SMTP had an option to 
provide an Identity (domain name) separate from the hostname, maybe with a 
syntax like HELO hostname(_at_)domain, but this will never happen.  It might be 
possible with an SPF record, however, to have an option like op=helo, and 
have that mean - you can use this record to authenticate any HELO name 
*ending* in the domain name of the SPF record.
There is less flexibility in this than hostname(_at_)domain, but for our 
purposes, it really isn't necessary to allow the domain owner to put the 
"zone cut" anywhere but the "domain" level for that branch of DNS (level 2 
for .com, .net, ...; level 3 for .us, .uk, ...).  If a domain-owner is 
really unhappy with our assumption about the proper level for his domain 
name, he can jigger his HELO name to get the desired effect.  e.g. if the 
Department of Environmental Quality in Pima County, Arizona, really wants 
an email reputation separate from the rest of Pima County, they can change 
their HELO name so instead of ending in deq.pima.az.us, it ends in 
deq-pima.az.us.  Of course, if they only send 5 emails a day, it might take 
a while to accumulate a good reputation.
> > We need a way to generate a complete list of authorized HELO addresses by
> > "compiling" an SPF record.  We can't ignore ?all, ptr mechanisms,
> > %{macros}, and other stuff that prevent such a compilation unless there is
> > some signal from the domain owner stating that this is his intent.
>
> "compiling" is just a performance hack.  It doesn't change SPF results.
Correct.  Performance is important for the Registry.  When we get a query 
on a domain, we want to return a single packet with all the information 
needed to assess the domain reputation, and authenticate its many 
authorized transmitters.  We want that information to be good for 24 hours, 
so a big receiver might send only one query on that domain, not thousands 
per day.  Methods that require multiple queries will not be allowed to 
burden the initial HELO check.  These queries will come later, when running 
a method that the sender has listed in their Registry record, and the 
receiver has implemented.
The goal here is to avoid any possibility of DoS attacks involving Registry 
records.
-- Dave


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?list_id=735