Re: CSV (Crocker's draft) good! (evaluation, big suggestion)

--Philip Miller <millenix(_at_)zemos(_dot_)net> wrote:
> Alan DeKok wrote:
> > "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
> >
> > > The thing I don't understand about HELO schemes is what they buy that we
> > > would not get from simply requiring senders to give a domain name that
> > > correctly resolves to the ip address of the sender sever.
> >   A little more flexibility.
> Additionally, specifying first a scheme for validating HELO allows easy
> extensibility to other 'identities'. In SPF syntax, the record used to
> mean "any MTA that can call itself example.com can send with MAIL FROM:
> *(_at_)example(_dot_)com" could simply be "v=spf1 helo".

I'm not sure what this paragraph means.  If you're trying to validate 
whether a HELO name is OK for that MTA to use or not, that's a different 
matter from tying HELO name to MAIL FROM authorization.
Personally, I approve of checking the HELO name against its domain, and 
then validating the MAIL FROM against its (possibly different) domain and 
not to try and relate the two.  In other words, I don't like the idea of 
validating the HELO name and then trying to "extend" or "infer" some other 
authorization by it.  I think any proposal to "extend" HELO protection to 
other data points can be written more simply without relying on the HELO 
part.  HELO checking is cool, but I don't accept the premise that it's a 
stepping stone to other validations.
SPF already provides (optional) protection against other people using your 
domain as a HELO name, in addition to the normal MAIL FROM protection.  You 
don't need a helo keyword.
It's also normal for your MTAs to have their own SPF records (like 
mail1.example.com) in addition to the record you have for your main domain 
(like example.com).

> This provides some separation of accountability for the MTA itself vs.
> the messages transmitted through it. Perhaps major ISPs, e.g. AOL, would
> want to protect themselves from random MTAs claiming to be AOL systems,
> but not want to immediately stop their users (and others, of course) from
> using MAIL FROM jrandomusername(_at_)aol(_dot_)com(_dot_)
>
> This is, I think, a useful gradation.

Hmm, how to specify that a certain name may not be used as HELO but can be 
used in other contexts?  I think there's a way to do that using the %{l} 
(localpart) macro...  When checking HELO names the localpart becomes 
"postmaster", so if you limit who can send from postmaster(_at_)aol(_dot_)com it will 
keep people from using that as a HELO name as well (even if other 
localparts are unrestricted)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>