Michael Kaplan wrote:
The core of this concept is that questionable unauthenticated email
will be bounced
I hope you mean "rejected", unsolicited bounces are evil. If whatever
you do is some kind of "receiver generated SPF database" I also hope
that folks like me, where all legit mails get a PASS, and anything
else (including traditional forwarder scenarios) gets an SPF FAIL,
don't need to worry about your concept.
But I'm far from confident that that's the case, there are dubious
statements on your page. Example:
| A perfectly comprehensive SPF record would require every domain
| administrator in the world to constantly update their domain's
| SPF record; an impossible expectation.
As long as the IPs and/or domain names describing the "border" of an
alleged sender don't change the administrator has no reason to touch
her SPF sender policy.
Existing SPF cannot authenticate forwarded email.
To some degree it can, receivers are free to whitelist forwarders
based on a HELO PASS for the outgoing MTAs of trusted forwarders,
and forwarders are free to become redistributors, i.e rewrite the
MAIL FROM.
overcome this other major flaw with SPF
JFTR, that's only the short story. The long story is that this is
a major flaw in the "simplified" e-mail architecture, specifically
in RFC 1123 5.3.6(a), inherited by RFC 2821. In the "original"
RFC 821 architecture each hop (including forwarders) had to modify
the MAIL FROM resulting in a literal concept of "return path".
Actually SPF offers to fix this major flaw in the SMTP architecture
without "return routes" (see RFC 821 for the technical details, or
the summary in an appendix of RFC 2821).
Traditional RFC 1123 5.3.6(a) forwarding is broken by design. And
domain administrators publishing an SPF FAIL policy know that this
is the case, and accept that that their mail will be rejected by
receivers supporting SPF in traditional forwarding scenarios. It's
the price for getting rid of tons of bogus bounces for forged mails.
And nobody's forced to pay this price until they actually need it,
but I digress.
[RIA]
Innocent third parties will be relatively unaffected by erroneous
bounces.
If innocent third parties with an SPF PASS/FAIL policy are affected
your system is broken. Many SPF participants can't add BATV to their
setup, or won't even if they could for various reasons.
If innocent third parties without BATV or without SPF PASS/FAIL
policy are "relatively unaffected" they might have their own opinion
about this issue. As an example I'd never allow Outlook Express to
send "auto-responses". It's bad enough that I use this software at
the moment.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg