ietf-smtp
[Top] [All Lists]

Re: Has the IETF dropped the ball?

2005-03-10 04:55:01

At 04:49 AM 3/10/2005 +0100, Frank Ellermann wrote:

David MacQuigg wrote:

> a few common items for SPF and SenderID that share a need
> to communicate through a chain of forwarders.

"Sender-ID" requires a worldwide upgrade of many mailing lists
and news servers (for moderated NGs), it's somewhat beside the
point of RfC 3834 chapter 4, in other words it's a FUSSP with
the decent charme of C/R-systems, and it breaks many published
v=spf1 policies by a SHOULD, now obsoleted by a NOT RECOMMENDED
in the SPF draft.

I do not believe in worldwide upgrades, it's against my KISS
religion.  And I do not believe in a NOT RECOMMENDED SHOULD.

Is this failure due to fundamentally incompatible methods, or due to a failure of the standards process? What if the standard said each method could have its own label and record format ( v=spf2, v=sidf1, v=dk1, etc. ). A single standard query would return whatever authentication information was provided by the domain in question. If a forwarder supports only spf2, and the domain provides only dk1, the authentication result passed on by that forwarder would be "None". Alternatively, the spf2 process could try and do the best it can with the dk1 information it is given. If the dk1 folks are sensible, they won't make their record formats too difficult for an spf2 process to use. In fact, if the standard is done right, there will be no incentive to make things difficult at this point, and the warring camps might actually put some of their technical genius on the task of making things more compatible, not less.

Could all methods live within this standard? This is a very simple question. Please don't respond with a flood of technical detail.

> We just need to provide a common protocol to handle the
> results of a Recipient having decided something is spam.

An SPF FAIL is not necessarily spam.  As long as the receiver
rejects all FAILs the sender can check what's going on.

I'm talking about Spam Bounces, not SPF Fails. I don't see a problem with authentication failures generating an immediate reject. An SPF reject should be treated like a one-time failure of the communication equipment, and fixed promptly. Mis-routed Spam Bounces are an ongoing problem, however.

Here is what I have so far in my Email Forwarding Protocol
http://www.ece.arizona.edu/~edatools/etc/Email%20Forwarding%20Protocol.htm
Fundamental Requirements
7) Spam Bounces in an IP-authenticated transfer must go back the path they came,
not to some header address that might be forged.  Forwarders must accept Spam
Bounces resulting from messages they have forwarded within a reasonable time,
and must attempt to forward these bounces to the next upstream domain.

Is this something all sides could live with?

> My frustration is partly due to the lack of progress on what
> I see as simple problems.

SMTP should be "simple", but obviously we are unable to agree
on a concept for MAIL FROM, the 1123 / 2821 fans insist on a
"feature" where the 821 / SPF fans cry "bug".  "Sender-ID" was
a foul compromise, beaten to death from both camps.  I could
live with it if it would only leave v=spf1 alone.

Is this issue really something that must be worked out in a shared standard? Could we not leave it to each competing method exactly which header it chooses for the domain name to authenticate? There is even room here for a patented algorithm!! Just not in the shared standard.

-- Dave


*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *