On Fri, 23 Apr 2004, Harry Katz wrote:
-----Original Message-----
From: Jon Kyme [mailto:jrk(_at_)merseymail(_dot_)com]
Sent: Friday, April 23, 2004 2:46 AM
To: Harry Katz
Cc: IETF MARID List
Subject: Re: Can you ever reject mail based on RFC2821 MAIL FROM?
So, I would like to propose a challenge to the MAIL FROM
advocates:
I wouldn't consider myself an "advocate" but...
publisher says something like:
"mydomain.example.com: only nnn.nnn.nnn.nnn applies_to 'MAIL FROM'
# we know this means our mail might not be forwarded # but we're OK
with that.
# And indeed, we're sure that our recipients are OK with that.
# Besides, it makes our stupid email disclaimers slightly # less
stupid
"
Now, *you* tell me what's wrong with that.
Sorry, Jon, that won't work.
Suppose alice(_at_)mydomain(_dot_)example(_dot_)com sends mail to
bob(_at_)alumni(_dot_)almamater(_dot_)edu(_dot_) But bob has set up
forwarding of
bob(_at_)alumni(_dot_)almamater(_dot_)edu to bob(_at_)company(_dot_)com
On the first hop from mydomain.example.com to alumni.almamater.edu, the
message has MAIL FROM: alice(_at_)mydomain(_dot_)example(_dot_)com(_dot_)
Everything's cool.
On the second hop from alumni.almamater.edu to company.com, the message
still has MAIL FROM: alice(_at_)mydomain(_dot_)example(_dot_)com because
alumni.almamater.edu hasn't implemented SRS, say.
Now company.com does the check of MAIL FROM and erroneously rejects the
mail because it is coming from alumni.almamater.edu's MTA which has the
wrong IP address.
This is a known issue.
SMTP has lots of "features" that relies on honesty.
Isn't it time to rethink. SMTP is not used anymore in honesty, maybe it
was back in '82.
The sending MTA _has_ to be responsible for what
is going out regardless of who is forwarding what, thus it has to rewrite
the 2821 MAIL FROM: but perhaps keep the 2822 From:.
We have to do some surgery on SMTP/ESMTP to make it work again.
I think honest people won't have a problem upgrading software just
to reduce forgery/spam.
It'll take them a fraction of the time they spend today on controlling
incomming spam right now.
There is a strong will "out there" to do some kind of 2821 checking.
The loss of todays ".forward" wont be a big problem compared to the
spam/forgery problem.
I agree with the previous poster. Split the problem into two.
2821 and 2822.
Best regards/Med vänliga hälsningar
Mattias W E