spf-discuss
[Top] [All Lists]

Re: HELO versus MAILFROM results

2005-05-04 08:20:46
wayne wrote:
In <4278CCBD(_dot_)2040207(_at_)ohmi(_dot_)org> Radu Hociung 
<radu(_dot_)spf(_at_)ohmi(_dot_)org> writes:
Mark Shewmaker wrote:

From section 2.1 of 
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre5.html 
:

| It is RECOMMENDED that SPF clients check not only the "MAIL FROM"
| identity, but also the "HELO" identity
[...]
| If the HELO test is performed, and results in a "Fail",
| the overall result for the SMTP session is "Fail",
| and there is no need to test the "MAIL FROM" identity.

I would suggest that checking HELO with SPF is misguided at best.


HELO checking in SPF has existed since the earliest draft of the SPF
spec that I have found.  (about 2 years old now...)  This form was
limited to using the HELO domain when the MAIL FROM was null.  About a
year ago, this was liberalized to saying that you MAY checked the HELO
domain in all cases, and in the schlitt-spf-classic-00 draft, it was
changed to SHOULD.

While there have certainly been people who have argued against HELO
checking in SPF, the clear majority have argued for it to be extended
to its current form.

You have listed many of the same anti-HELO-checking arguments that
have been listed before.  I will not repeat the pro-HELO-checking
arguments as they are found in the spf-discuss archive.

That's fine... however, if your spec if incompatible with other RFCs,
especially mainstream RFCs such the 2821, I think it will be hard to get
it passed as an RFC.

Perhaps an informational RFC would be a better goal in this case. The
purpose of those is to document how things are, not how things should
be. That would be more in line with your stated goal for the current SPF
draft.

Also, the fact that you suggest lookups on an SPF RR, when one is not
defined, will also not go well, I believe.

Personally, I think it is flawed to assume that an eventual SPF RR will
take a form as inneficient for SPF purposes as text strings. A binary
format closer to your "byte compiled" syntax in libspf2 is more likely.

In fact, I am presently working on an RFC for this SPF RR, and it will
specify a binary format, along with some new features not yet seen, in
order to maximize the amount of useful information conveyed in 512
bytes. (ie, it's not useful much to repeat the substring " ip4:" 10
times per record)

Whether my RFC will pass or some other RFC will pass instead is
irrelevant. In your draft, you assume (I think) that SPF RRs will be
made of text strings, and that is unwise.

Regards,
Radu.

-------
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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature