Stuart D. Gathman wrote:
SPF softfail - because the sender is asking for debugging
help
ACK, kind of solicited. If they get too much they can switch
to FAIL. Or fix any missing NEUTRAL / PASS IPs.
SPF NONE, no PTR, invalid HELO, no guessed pass (3 strikes)
Is that "invalid HELO" defined as "NXDOMAIN" ? You could also
reject this. Maybe RFC 2821 mumbles something about "only for
logging", but you're free to reject any mail if you don't fear
RFCI listings.
there are a LOT of otherwise legitimate senders with this
braindead setup.
The "PTR required" draft is expired at the moment. You can
make your own rules until you hit a BL with different rules ;-)
It causes a lot of problems to simply reject them because
they are clueless (or they would have done it right) and
don't know what to do.
ACK. But I've read somewhere that 84% of all mails are spam,
11% misdirected bounces, only 5% are legit. If you care too
much about the 5% you contribute to the 11% making it worse
for innocent bystanders.
With a reject it's the problem of the sender to figure it out.
clients are concerned about missing email from email-clueless
customers.
Tricky. Maybe add some decent BLs to the reject-logic, if you
want to send DSNs you can take aggressive BLs - a recipe as for
an outsourced backup MX while the primary MX is down.
Spamcop suggests using another public IP for DSNs. This is
reasonable and feasible for most of my clients.
Yes, it won't hurt you if this IP is blocked. I'm no big fan
of this strategy, my ISP is too timid to block aggressively, in
other words the DSNs you send will be dumped in my mailbox. :-(
If I've time for this I spamcop it... okay, not really in your
case, you'd see the SPF FAIL for mails claiming to be from me,
therefore I won't get misdirected bounces from you, no problem.
Eventually those clueless senders need to get a clue.
It's your decision, you can accept NONE like PASS and follow
the obsolete 2821-rules, or you can treat it like FAIL for any
plausible reason. Clueless senders should understand a reject
if you state this plausible reason in the 5xx response. Maybe
add an URL of the boilerplate explanation instead of putting
it into a DSN.
Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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