-----Original Message-----
From: Greg Connor [mailto:gconnor(_at_)nekodojo(_dot_)org]
Sent: Monday, April 26, 2004 12:58 PM
To: Harry Katz; ietf-mxcomp(_at_)imc(_dot_)org
Subject: RE: Can you ever reject mail based on RFC2821 MAIL FROM?
[snip]
trusted-forwarders.org is such a whitelisting service, and it seems to
work.
This may be a fine list during early development or beta testing. But
are you suggesting this needs to be a permanent part of the MARID
solution? Based on the experience of similar list providers, I would
guess that both DDOS attacks and litigation will follow.
[snip]
If the forwarder IS doing MAIL FROM rewriting, what
precisely is it that
the receiving user is supposed to whitelist? The rewritten address
containing a randomly inserted cookie? The forwarder's
entire domain?
Hello, uh, you were asking what needs to be done IF SRS is
not used, so
it's going to be a bit confusing if you change the question
around after
the answer is given.
But to answer your question, the whitelisting is a workaround
for non-SRS
forwarders and their users. It is not needed for SRS forwarders.
Of course, you're right. My mistake. Please ignore.
[snip]
I'm certainly willing to have a reasonable discussion here,
but if you're
going to be evasive, dismissive, or continue to take a
condescending tone,
I'm going to choose to focus my time on responding to
*sincere* discussion
rather than your style of discussion.
Perhaps you're not being "deliberately" abrasive, but I think
if you wanted
to tear this group apart from the inside you're making an
admirable start.
It's not my intent to be condescneding or abrasive and I apologize if my
words came across that way.
What I am trying to do is draw attention to the fact that relying solely
on 2821 MAIL FROM as a way to both reject lots of mail and prevent false
bounce messages carries serious risks and relies for its effectiveness
on near universal adoption of SRS or similar schemes.
I eill look more closely into Pete Resnick's idea of using RCPT TO
and/or ORCPT.
I have also been trying to draw attention to the fact that we can't
succeed in restoring user confidece in the mail system unless we attack
the phishing problem. Likewise, we must provide a mechanism for
legitimate senders to protect their brands from such fraud. That means
we also need to look at the 2822 headers. In this context I do agree
with your point on another post that it's critical that domains are able
to express a single policy that covers both 2821 and 2822 validation.