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

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.
I'm saying the following:
1. It would be good to validate HELO names.
2. Validating HELO can allow some conveniences in validating MAIL FROM.
I think the best example of this would be a company, example.com, that 
outsources some bulk messaging to another provider, example.net. Each would 
list their own servers as authorized to claim HELO in that domain. For MAIL 
FROM, example.com would authorize any server that can claim HELO in 
example.com or example.net. Clearer?
> 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.
HELO checking is neither necessary nor sufficient for other validations.
It's simply a nice feature that could make some situations much easier to 
handle.
> 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.
The HELO keyword was intended to mean (hypothetically, not necessarily in 
the way SPF works) "servers that can claim to be members of this domain can 
send mail from this domain". I probably shouldn't have used SPF as an 
example, because it does indeed confuse what I was suggesting.
> 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).
What purpose do such records serve? Are they only really used when dealing 
with MAIL FROM: <>?
> > 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)
The SPF-syntax example I provided was purely illustrative. Perhaps it would 
have been clearer if I used to outsourced provider example?
All I was saying was that if we choose to validate HELO, being able to 
reference said validation for other parts can be useful.
Philip Miller