spf-discuss
[Top] [All Lists]

Re: overall HELO FAIL

2005-05-26 17:31:14
In <429658B4(_dot_)2655(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann 
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:

That's messy.  Senders need a clear understanding of the
SPF matrix:
             |               MAIL FROM
HELO         | PErr | FAIL | Terr | S.F. | N.N. | PASS |
-------------+------+------+------+------+------+------+
PermError    |      |      |      |      |      |      |
FAIL         |      |      |      |      |      |      |
TempError    |      |      |      |      |      |      |
SOFTFAIL     |      |      |      |      |      |      |
NEUTRAL/NONE |      |      |      |      |      |      |
PASS         |      |      |      |      |      |      |


I don't think such a matrix can be filled out.  First off, as
discussed during the "HELO versus MAILFROM results", this is generally
implemented more as an algorithm than a combined result.

I expect the algorithms that people use will change over time, making
it very unsuitable to be included in the spec.  I expect that the
algorightm will vary by the receiver, making such a table useless for
a sender.


Right now, I would recommend some sort of algorithm like this:

If SPF(HELO) is not either Neutral, None or pass, reject the
connection and don't even let the client SMTP connection get to the
MAIL FROM command.

If SPF(HELO) is PASS and the HELO identity is a known, good forwarder,
then override the MAIL FROM result

Otherwise, use the MAIL FROM result to decide what kind of SMTP
response codes to use.


The "receiver policy" mantra has its limits.

True, but it also has some basis in reality.  


I also think the mantra that "it must be compatible with
draft-mengwong-spf-*" has its limits.

But, it also has quite a bit of basis in reality.


-wayne



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