[Asrg] Re: Receiver Initiated Authentication

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".

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related ietf.org Links asrg imrg Request more information about Pantek

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