On 24 Feb 2004 at 11:40, Theo Schlossnagle wrote:
SPF is designed to prevent fraudulent use of a domain the the return
path. The EHLO is not part of the the return path as I see it -- it
isn't even required. It appears in the trace headers if your MTA is
responsible enough to add it. To me SPF is not designed to prevent
abuse of the null envelope sender problem. And in my opinion, that is
fine. No one is fraudulently using my domain in their null envelope
sender.
I don't understand what you call "null envelope sender". The problem
here is forging the HELO string (sending client name). Maybe it's not
your case, but I can tell you that spammers are using my domain in the
envelope HELO string. And even if this is just a string in the Received
headers, it's still enough for many people to think I am responsible for
the spam.
I get around 2-3 UBE-complaints each day. I haven't counted exactly yet,
but probably a third of them complaint to me because of a forged HELO
string (baschny.de appearing in the Received-headers), the other two
thirds forged From-strings. It is a problem, and the "sender policy
framework" is already armed to handle this kind of forgery, it's just
not aborded this way in the specification.
SRS happens to be a technology/methodology design to tackle the null
envelope sender problem (and other things).
What "other things" do you refer to?
I see no reason by SPF has to "do it all". It has a stated purpose and
the current specification fits that purpose.
In my view, also checking the HELO for SPF also fits the stated
purpose.
--
Ernesto Baschny <ernst(_at_)baschny(_dot_)de>
http://www.baschny.de - PGP: http://www.baschny.de/pgp.txt
Sao Paulo/Brasil - Stuttgart/Germany
Ernst(_at_)IRCnet - ICQ# 2955403