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

On Mon, 2004-05-03 at 20:34, Greg Connor wrote:
> --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.
What can be useful first?  Currently there is no means of knowing
ownership of an SMTP client without a prior relationship.  A specific
DNS record matching the HELO domain clearly indicates administrative
responsibility for policies of this SMTP client.  This domain will be
credited for messages relayed, forwarded, or originated.  If these
policies ensure valid messages, this check is sufficient and, if there
is a problem, only this domain is held accountable.  Otherwise, header
forgery could credit other domains not responsible for the message.

Once this SMTP client is trusted and envelope rewriting is in place,
further checks can be made to detect unverified 'from' addresses. 
Assigning credit for such messages would be predicated on trusting the
SMTP client.

> 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)
The helo domain is not a user?