Greg,
Thank you very much for your clarification. I got one other message out
before this came in, so again, I am looking a bit on the clueless side in
that message.
FWIW, my agenda is simply as one whose company domains have their
identities stolen for misuse in spam. As such, I am vitally interested in
preserving the reputation of my company domains and am therefore an SPF
publisher. It seems that this issue of HELO/EHLO is one for the MTA
developers supporting SPF and not for the publishers. Sorry to add more
noise and less signal.
In any case, your message helps enormously and clears things up for me.
Thanks,
Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/
At 02:52 PM 12/10/2004, you wrote:
On Fri, 10 Dec 2004, Commerco WebMaster wrote:
> David and List,
>
> I too like the idea of separating the HELO/EHLO processing from SPF,
> perhaps because I am still not completely sure why helo checking is being
> done. Sorry to be clueless.
Hi Alan,
I don't think it's an issue of being clueless. I think the HELO issue has
been confused by much discussion of CSV, and unclear communication from
the SPF official website.
This is what I know: The original spec for SPF which most implementations
are
based on (i.e. all that I know of) had HELO checking required in the case
where MAIL FROM is <> (i.e. bounce messages). This has been part of the spec
for over a year.
More recent implementations also have HELO checking available for ALL
messages, as an optional feature that the receiver can turn on.
When I was first introduced to CSV, I said, "But wait, SPF already has HELO
checking, can't we just use that?" For various reasons, CSV supporters
maintain that CSV is actually better than SPF HELO checking; I don't really
buy this, but they have their reasons. However, CSV can't claim to be the
only one (or even the first one) on the scene to provide HELO checking,
though
CSV folks may want you to believe it.
My suggestion is that for the purposes of defining the SPF Classic (v=spf1)
spec, we should follow Wayne's suggestion and document SPF Classic by
following the existing implementations as closely as possible, including HELO
checking on MAIL FROM: <> and optional HELO checking always if the receiver
wants it. (When it comes time to define Unified SPF it should be just
another
scope, so we can write spf2.0/helo records, or check the scope macro or both.)
Thanks
gregc
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"
-------
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