spf-discuss
[Top] [All Lists]

Re: Re: Possible SPF machine-domain loophole???

2004-02-26 11:29:40
--Hector Santos <winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:
Yesterday (Feb 25),  we got 6 transactions which exploited the SPF
loophole. Here is a summary of the transaction logs:

**************************************************************************
SMTP log started at Wed, 25 Feb 2004  13:23:50
Client IP: 206.66.146.23 (unknown)
13:23:51 C: EHLO santronics.com
13:23:51 C: MAIL FROM: <reynoldcgin(_at_)altavista(_dot_)com>
13:23:51 C: RCPT TO: <andrea(_dot_)santos(_at_)santronics(_dot_)com>


Hmmm, I wonder why SPF didn't stop this message, altavista.com supports SPF.


My suggestion for a "change in SPF lookup logic" is to return the #1
benefit that all LMAP proposals provide - at a minimum check for Local
Domain HELO Spoofing and optional as a system implementation option,
check for remote domain HELO spoofing.   You don't have control of remote
configurations with unknown domains and results.  But you do have full
control of your own setup and you definitely don't want others using your
domain names in the transaction.  That is an easy trap - which SPF has a
loophole in checking when the return path is not local and not null.


OK, I will agree with the suggestion, but I still strongly object to your characterization of this "lack of feature" as a "loophole". A colander can be used to hold grapes, but not beer. Is that a loophole, or a design decision?

You may think I am being picky here, but there are GOOD reasons why HELO checking was not turned on for all mail, and is only required to be used when the sender is <>. HELO name is just bad data and can't be counted on to be a fqdn. There is a GOOD reason not to use it as a primary input. If we limit our exposure to <> mail, then we limit the damage done by bad configurations - it is only the bounce/NDN messages that are lost, not all mail from that server.

I am *willing* to *consider* that more HELO checks *could* be performed, but this also adds even more processing time and complexity to the receiver, so we should tread very carefully here. I don't think it should be a requirement... I think it should be left as optional, at least in the 1.0 version.

Your repeated insistence that this is a Flaw, Loophole, Lack, Problem, etc. is NOT helping to win friends. I am not impressed by your behavior. I think it is selfish and irresponsible for you to continue to describe SPF in derogatory, possibly insulting terms, when it is clear that you don't quite understand why the decision was made in the first place (and have not made an effort to understand).




--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>