Re: SPF HELO checking

David and List,

I too like the idea of separating the HELO/EHLO processing from SPF, 
perhaps because I am still not completely sure why helo checking is being 
done.  Sorry to be clueless.
Even so, given that the checking might be done, for selfish reasons, I 
would suggest a slightly different implementation.  Since this checking 
seems something of a device to confirm a mail server's SMTP/ESMTP 
HELO/EHLO, perhaps we could title it cmtp1 (Confirm Mail Transport Protocol 
TXT record version 1).
Since it relates to SPF, perhaps we could add something in SPF like HELLO 
to simply indicate that we are supporting some additional DNS TXT records 
for confirmation of the sending SMTP/ESMTP server's HELO/EHLO.  Arguably, 
if the MTA is checking for such things anyway, this is an unneeded 
enhancement to SPF if HELO/EHLO checking is being broken out of SPF.
Thus:
example.com. IN TXT "v=spf1 ip:192.168.1.1 hello=cmtp1 -all"
- To mean example.com sends from IP 192.168.1.1 and uses cmtp1 hello checking

example.com. IN TXT "v=cmtp1 -all"
- To mean example.com should not be seen as a HELO/ELHO

NOTE: for this example, mxsender.example.com=192.168.1.1

mxsender.example.com. IN TXT "v=cmtp1 
hello=mxsender.example.com.someotherstuff -all"
- To mean when you get a message from mxsender.example.com, the HELO/EHLO 
had better look like what follows the hello=.
I realize this might seem a bit goofy, but if the HELO/EHLO for 
mxsender.example.com is not identical to the DNS name, it might cause 
rejections that the SMTP/ESMTP server owner would prefer not happen.  That 
relates to the selfish part I mentioned above, but I think that it also 
allows some flexibility to also handle what David needed in his 
attached.  The reverse of David's need could also be handled in this way.
For example:
mxsender.example.com. IN TXT "v=cmtp1 hello=example.com -all"
- To mean, even though the message is coming from mxsender.example.com, its 
HELO/EHLO is always going to be example.com.
even better:
example.com. IN TXT "v=cmtp1 hello=example.com -all"
- To mean, no matter where in example.com the message came from, it is 
going to have its HELO/EHLO as example.com
I'm not sure that doing that is a good thing.

One could even extend the cmtp1 record to include clues about such things 
as use of keys or encryption, which would then cause an MTA supporting such 
checking to move on to those kinds of records or directly get included in 
the cmtp1 record.
Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/



At 12:30 PM 12/10/2004, you wrote:
> Hi !!
>
> > I also think that because HELO is expected to be hostame that SPF record
> > should just directly list its ip (or ip block where it is located, but
> > this ip block should not be as wide as for mail-from) or at most include 
> > reference to one dns lookup (i.e. like mx operator) but no complex 
> > inclusions, references or complex macros that maybe usefull for
> > some case of MAIL-FROM SPF records.
> one step further ... I want my domain (ols.es) to have an spf record
> like "mx ~all", but i don't want anybody to use ols.es in the hello,
> including me (as i always use full hostnames in my hello). How can
> I specify this policy ??
>
> so, i agree, hello policy must be separated from mail from: policy.
> Then , what about having something like this:
>
> ols.es. IN TXT "v=spf1 mx ~all"         -> for mail from:
> ols.es. In TXT "v=hello -all"           -> to prevent hello forgery
> a.lon.olsns.net IN TXT "v=hello a -all"  -> for my hello's
> a.mad.olsns.net IN TXT "v=hello a -all"  -> for my hello's
>
> and always make hello checks agains hello records (not only in the
> case of the null envelope sender)
>
> --
> Best regards ...
>
> ----------------------------------------------------------------
>    David Saez Padros                http://www.ols.es
>    On-Line Services 2000 S.L.       e-mail  david(_at_)ols(_dot_)es
>    Pintor Vayreda 1                 telf    +34 902 50 29 75
>    08184 Palau-Solita i Plegamans   movil   +34 670 35 27 53
> ----------------------------------------------------------------
>
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
> To unsubscribe, change your address, or temporarily deactivate your 
> subscription, please go to 
> http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com