[Meng Weng Wong]
I punted again.
It is RECOMMENDED that the <responsible-sender> be drawn from the
envelope using this algorithm:
The <responsible-sender> comes from the domain name of the "MAIL
FROM" envelope sender. When the envelope sender has no domain, a
client MUST use the HELO domain instead. If the HELO argument does
not provide an FQDN, SPF processing terminates with "unknown".
I'm a little confused by the above. It appears to be a RECOMMENDED method
for extracting the <responsible-sender> for display in the MUA, which is a
post-SMTP session task. However, the end of the last paragraph says to
terminate SPF processing and return UNKNOWN in the case of malformed
envelope-sender of HELO string. These normally occur during the SMTP
session, so I'm confused. I could easily be confused by seeing this section
out of context and I apologize in advance if that's the case, but here's my
question.
Depending on how you interpret the above, a spammer can forge the envelope
sender to have no domain and send it though an MTA that does not HELO with
an FQDN and SPF can still return UNKNOWN. Since it will probably be quite a
while before most sysadmins will be willing to reject messages based on an
SPF result of UNKNOWN, doesn't this build a gaping hole for spammers?
I know there are a lot of misconfigured (or unconfigured) MTA's that don't
HELO/EHLO with an FQDN, but why shouldn't this be a FAIL (preferably hard)?
This seems fundamentally different from the situation where the
envelope-sender has a domain that exists, but with no SPF record, and an MTA
that has a HELO/EHLO string with an FQDN that also exists and matches the
connecting IP. UNKNOWN seems appropriate for the latter and allows phase-in
of SPF. However, an envelope-sender without a domain, or with a
non-existent domain, and/or an MTA without an FQDN in its HELO/EHLO string
or an FQDN that doesn't exist or that doesn't match the connecting IP looks
a lot like a forgery. It _may_ simply be misconfiguration, but it does
_look_ like forgery. So why not return FAIL for that case? They can change
their configuration easily and they will have no further problems.
--
Seth Goodman
off-list replies to sethg [at] GoodmanAssociates [dot] com
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡