Douglas Otis wrote:
There is no means to know which recipient may be using a
forwarded account.
Yes, it's a "sender policy", not a "recipient's policy", and
not a "mediating source policy" (one of the mail-arch terms).
Forwarding is a common practice within colleges, societies,
and many providers.
Sure, there's nothing wrong with forwarding, each and every
mail I send is forwarded at least twice, from me to a smart
host, from the smart host to an MX of the recipient, or to
an MDA in the case of local users.
What happens beyond the MX of the recipient is none of my
business, as you say there's no way for me to know what the
recipient does. My "sender policy" cannot cover forwarding
by the recipient. If he wants this for some reason, he has
to use his own MAIL FROM and his own "sender policy".
Validating the legitimacy of an MTA can take place within
a single lookup of a small CSV-CSA record.
Fine, I've no problem if my mail providers do this for their
smart hosts, or if they test it for incoming mails at their
MXs. CSV / SPF / SPF+CSV / ... are all okay, as ar as I'm
concerned.
With the change being made, the HELO may now be checked
against a record found at the zone apex.
The "zone cut" isn't a new feature, it was in the last SPF
draft published before MARID. BTW, Tony's blog mentions that
CSV now also solved this problem, but I don't find how, it's
apparently not in the last (now expired) CSV draft.
Here's a summary of my SPF experiences in the last 10 months:
Mar 04: some spammer(s) start to abuse "my" vanity domain, I
get about 1000 erroneous bounces / vacation mails /
challenges / etc. per day.
Apr 04: My ISP publishes a sender policy. Intuition or bug,
neither my ISP nor me saw the "minor" problem, that
this sender policy didn't cover "my" vanity domain.
May 04: Wildcard added, now it works even without "zone cut".
"Zone cut" also added to the SPF draft replacing an
older "match_subdomains" construct.
Sep 04: 180,000 bounces etc. so far in my mailbox (JFTR, I'm
a modem user)
Oct 04: My spammer(s) got the SPF idea, again zero bounces
etc. per day
Jan 05: So far not a single problem with SPF from my POV, and
4*30*1000 = 120,000 avoided bounces etc. since Oct 04.
You can discuss "the better is the enemy of the good" in MASS
and CLEAR as long as you like, I have what I wanted, and SPF
was good enough for me. Let them all disable SPF as soon as
something better exists and works, no problem.
I agree, the overhead for HELO checking would be unacceptably
high with SPF
Where that's the case (it depends on the sender policy) the
sender could arrange his HELO domains to avoid it. And if CSV
has a better solution than SPF's "zone cut" for spoofed HELOs,
I'd be interested what it is - I'm always curious.
when publishing SPF, expect some of your mail to be lost or
rejected due to problems with either SPF et al or Sender-ID
algorithms. This is shameful.
No legit mail is "lost" with SPF, that's FUD. While MARID was
a shameful disaster, one of the few results was, that Sender-ID
evaluations of SPF sender policies generally do _not_ work.
those that have published what is now considered too many
records may find their mail being rejected.
If an erroneous policy "worked" with old SPF implementations,
and new implementations report the error, then it's time to
fix the old error.
The SPF timeout imposed still ignores UDP fallback.
The overall SPF timeout in old drafts was replaced by clear
processing limits, which don't depend on a vague accumulated
processing time.
| Records that are too long to fit in a single UDP packet MAY
| be silently ignored.
Is it reasonable to expect the receiving SMTP server to
perform a hundred lookups per message?
No, that's why it's impossible, you have constructed a worst
case of 1+10+10*10 = 111 DNS lookups for a sender policy with
10 mx directives, each with 10 MX hosts.
The average case is probably more like 1 to 4 lookups, I've no
data to support this guess. And not necessarily per message,
if you'd use CSV or SPF or an RBL to block an IP or to reject
all mails after your HELO-test resulted in a FAIL, then you
won't test the individual messages in this SMTP session.
This can be safely achieved via the efforts in MASS and
CLEAR, but not with SPF.
Please inform "us" when that's ready and deployed. Bye, Frank