LuKreme wrote:
On 2-Dec-2008, at 20:21, DJ Lucas wrote:
I can find absolutely no reason to inadvertently mislead, or worse,
intentionally deceive the recipient by forging the envelope sender's
address. In fact, the only reason I can see, is to intentionally
deceive the recipient. Is there any other reason?
Sure there is. First off, the envelope from is not FOR the user, it's
for the mailserver. This address should always be where the
'physical' delivery of the message is originating. The From header is
the PERSON that initiated the message. These are often the same, but
not always.
A perfect example is my mom sends out electronic cards from Jacquie
Lawson<1> which arrive with headers like this:
Return-Path: <[EMAIL PROTECTED]>
Received: from iport3.jacquielawson.com (iport3.jacquielawson.com
[64.14.122.52])
by mail.covisp.net (Postfix) with ESMTP id D4AD9118B83F
for <[EMAIL PROTECTED]>; Thu, 27 Nov 2008 02:27:05 -0700 (MST)
Date: Thu, 27 Nov 2008 04:27:02 -0500
X-AG-MIPS: ag867
Sender: <[EMAIL PROTECTED]>
From: **my mom**
I don't see how this particular case would be affected. The only
"forged" part was in the header that I can see from your example, not
the actual MAIL FROM during the initial part of the SMTP conversation.
Currently I have our configuration set to reject mail claiming a MAIL
FROM that originates in our domain if the session has not been
authenticated or coming from the local network.
Example where MAIL FROM is not forged, but From part of header is:
$ telnet mail1.omitted_for_privacy.com 25
Trying x.x.x.x...
Connected to mail1.omitted_for_privacy.com.
Escape character is '^]'.
220 mail1.omitted_for_privacy.com ESMTP
EHLO omitted_for_privacy.com
250-mail1.omitted_for_privacy.com
250-PIPELINING
250-SIZE 2147483647
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:[EMAIL PROTECTED]
250 2.1.0 Ok
RCPT TO:[EMAIL PROTECTED]
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: [EMAIL PROTECTED]
Subject: proof that only the mail from portion is rejected
This email should be accepted by our mail server
.
250 2.0.0 Ok: queued as 241056A006F
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Example where MAIL FROM is forged:
$ telnet mail1.omitted_for_privacy.com 25
Trying 12.48.244.4...
Connected to mail1.omitted_for_privacy.com.
Escape character is '^]'.
220 mail1.omitted_for_privacy.com ESMTP
EHLO judelawfirm.com
250-mail1.omitted_for_privacy.com
250-PIPELINING
250-SIZE 2147483647
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:[EMAIL PROTECTED]
250 2.1.0 Ok
RCPT TO:[EMAIL PROTECTED]
554 5.7.1 <[EMAIL PROTECTED]>: Sender address
rejected: Not authenticated
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
This is perfectly OK. In fact, this is exactly how this should be
handled.
I agree completely, I do not think it's OK to forge the MAIL FROM
portion of the SMTP conversation though. I think this is what DJ Lucas
was getting at.
This method is also used when someone is sending, for
example, a petition request where they've 'signed' and want to let
others know to sign also. Many pages (particularly political ones)
have these sorts of "tell your friends" links and they to will use the
person's email/name as the from and their own server info for the
envelope. I would be far more likely to take a look at the FROM_ and
compare it to the Received header than with the From: header, as I
think that is far more likely to spot spam.
Extending this to a physical letter situation it would be like Barack
Obama's campaign sending me a letter that was signed by, say, my mom.
She wrote the letter and signed it, but the campaign office mailed it
in their own envelope. Seems fine to me.
If they don't like my policy, they can find another place to put
their mail. Others may not be lucky enough to be able to enforce
such a policy, as the counter argument would be to find a less rigid
admin. ;-) What is 'acceptable' has to be determined on a site by
site basis. If it works for this site...great! If it doesn't, then
get rid of it.
Just so you know that there are common and legitimate uses for this,
and that you will lose valid emails that, presumably, your users
actually want. And if you are rejecting them, do your users know they
are missing those emails? I mean, are they informed enough that they
can make a real choice about getting MOST of their email from you or
getting ALL of their email from someone else?
<1> I have no connection with Jacquie Lawson. I'm not even a
customer, I am merely a recipient. I do like the cards though.
At this point I think there is some confusion about what is being stated
is acceptable and what is not.
