----- Original Message -----
From: "David MacQuigg" <dmq(_at_)gain(_dot_)com>
To: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Thursday, March 10, 2005 6:55 AM
Subject: Re: Has the IETF dropped the ball?
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?
This is perfect illustration of the administrative vs developer conflicts
that exist here, and in all other IETF areas that is addressing the "spam
issue."
You are thinking POST-SMTP processing as a bounce is only generated in ths
matter.
SORBIG-generation based hackers will lick their chops for sites running your
protocol. They will home in and seek your sites.
The concentration should be in eliminating the need for the bounce in the
first place - that is SMTP level. Not POST-SMTP.
Until these key differences are understood, we will continue to not get any
significant progress made.
Just look at this way:
If I have to put in resources dollars to change software to address 2822
analysis, what logic do you have that isn't going to work at 2821?
The bounce gos to the return path defined at 2821. So why do I need to read
the 2822 to get to the same conclusion you are a "bad sender."
What is the return path is invalid? You just increased the outbound queue
overhead to send the "get no where" bounce.
.... SENDERID...
Is this issue really something that must be worked out in a shared
standard?
The only share standard that can exist is a SMTP compliancy understanding.
Just look it this way:
If SMTP compliancy is not a requirement, then why should a spammer adapt?
He has no reason to do so if host systems must still honor their
non-compliant transaction.
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.
How does this apply to SMTP?
Are you suggesting some ESMTP attribute exposure of a requirement in the
2822 header in order to proceed?
What is the "header" doesn't exist?
Should the SMTP process accept just to check the header?
Should this be done at the DATA stage?
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office