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 *
************************************************************* *