spf-discuss
[Top] [All Lists]

Re: SPF HELO checking

2004-12-11 12:25:59
In <x4ekhyqj4x(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne 
<wayne(_at_)schlitt(_dot_)net> writes:

In 
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0412091138090(_dot_)31092-100000(_at_)sokol(_dot_)elan(_dot_)net>
 "william(at)elan.net" <william(_at_)elan(_dot_)net> writes:

I'm working on updating updating the SPF I-D now, [...]

One of my core goals with the new I-D is to having it remain as
compatible as possible with previous SPF specs.  


Again, I'm looking for justification of why the SPF checking policy of
draft-200406.txt and draft-schlitt-spf-00 should be changed.  I've
read comments from quite a few people, but so far, I do not see the
justification to change the semantics of previous SPF specs.


If I was to design SPF's HELO checking today, I would do things much
differently.  Maybe the removal of the scope= modifier from the earlier
SPF specs really was a mistake.  However, I think it is *WAY* too late
to change things now for SPFv1.

SPFv1 can support HELO checking, if you are willing to put up with
some ugliness.  It can do just about anything you want to do with HELO
verification.

  * In most cases, MTAs give a subdomain to their email domain on the
    HELO command.  Therefore, you can easily publish separate policies
    for legitimate HELO checking and MAIL FROM checking.

  * the %{l} is always set to "postmaster" for HELO checking and can
    be used to distinguish the scopes and to change the policy for
    HELO checking.
    
  * SPF HELO checking uses more DNS lookups than is absolutely needed,
    but not so many more to make it impractical.  


Furthermore

  * SPF HELO checking has been in the spec for 18+ months.

  * The SPF spec has, for all practical purposes, been frozen for 6+
    months, and in many ways has been pretty slushy for 12+ months. 

  * I did a quick survey of HELO domains that have recently been used
    to send email to me.  In the tiny sample, I found more published
    SPF records at the HELO domain level than there probably exist for
    all CSV publishers in the world.  I think we have a large enough
    installed base of SPF records preclude incompatible changes.

  * All SPF implementations that I know of will check the HELO domain
    in cases of a null MAIL FROM.  The install base of SPF
    checkers is large enough to preclude incompatible changes to the
    semantics of SPF records, including that all SPF records can and
    will be checked using the HELO domain in at least some cases.

  * There exists at least a couple of significant SPF implementations
    that are already always checking the HELO domain, even when the
    MAIL FROM is not null.  (SpamAssassin 3.0, AOL, Hector's systems,
    etc.)

  * The SPF wizard on spf.pobox.com has told you to create SPF records
    at the HELO domain level.

  * Over the last year or so, many people have suggested that, as a
    Receiver Policy, that when MTA servers (receivers) are doing HELO
    checking, they should reject on SoftFail, or even on Neutral (but
    not None).



-wayne






<Prev in Thread] Current Thread [Next in Thread>