ietf-smtp
[Top] [All Lists]

Re: Has the IETF dropped the ball?

2005-03-09 21:05:02

David MacQuigg wrote:

I agree that IETF shouldn't be doing the R&D.

The ASRG of the IRTF tried, one of the submitted papers was
http://www.simpleweb.org/ietf/internetdrafts/complete/draft-irtf-asrg-lmap-discussion-01.txt

That was one of the sources for the later MARID WG.  It was
crippled by the publication of Caller-ID and later the mixture
of Caller-ID and SPF styling itself as "Sender-ID".

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.

Notice I didn't say IETF should pick a winner right now
between SPF, SenderID, and DomainKeys.

So far they picked RfC 3865.  If that convinces bureaucrats
that a subject tag [adv] is not the FUSSP it's not so bad as I
thought.

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.

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.  Bye, Frank