ietf-mxcomp
[Top] [All Lists]

RE: FW: Can you ever reject mail based on RFC2821 MAIL FROM?

2004-04-23 11:54:49

 

-----Original Message-----
From: Mattias Webjörn Eriksson [mailto:mattias(_at_)webjorn(_dot_)org] 
Sent: Friday, April 23, 2004 10:28 AM
To: Harry Katz
Cc: ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: FW: Can you ever reject mail based on RFC2821 MAIL FROM?


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

While I agree with the spirit of what you are suggesting - to restore honesty 
to the Internet - the reality is we have a huge installed base of SMTP servers 
out there.  Even if we agreed today that all forwarding MTAS must rewrite the 
MAIL FROM, it will take years - many years - to upgrade them.  I strongly doubt 
whether we will ever entirely eliminate today's style of "verbatim" forwarding.

In the interim - which will last a long long time - we need a solution that 
does not falsely reject mail when forwarders do not rewrite MAIL FROM.     


<Prev in Thread] Current Thread [Next in Thread>