----- Original Message -----
From: "wayne" <wayne(_at_)midwestcs(_dot_)com>
To: "IETF MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, April 16, 2004 5:55 PM
Subject: Re: Rough consensus reached. Let's move on.
RFC2821 section 4.1.4 says, in part, the following:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Now, in my opinion, validating the HELO domain using both the IP address
*and* MARID info means that we can reject invalid HELO domains without
violating RFC2821. If I recall correctly, some people in the "Input
on identities" thread disagree.
Correct. This needs to get resolved. The fact is, we are already rejecting
on HELO:
- Invalidate domain literal, 20%
- Spoofed local domain, 12%
- Extended 220 Welcome lines stops 40% of the bulk spammers.
so by the time we even get to MAIL FROM, nearly 60-80% of the connections
are rejected or they drop on their own! See our stats
http://www.winserver.com/sslinfo which shows a consistency rate for the past
5-6 months in this area.
Guess what? One got one compliant about false negatives (rejections) in
this area from a sysop using the built-in PHP MailSend() command from his
local web site which has a problem with extended welcome lines. 1 compliant
only. Our fix was to not display the extended welcome policy file, if any,
for local network connections. But thats it. Its not our fault :-)
2821 FROM If this is present (i.e. not a bounce) the only reason
it might be inconsistent in a legitimate email is that
it was forwarded.
I know of no problems with validating the MAIL FROM, nor do I think
that requiring forwarders to change to using their own domain when
forwarding is in violation of any RFC.
I personally don't like the idea of dynamic alterations during a route.
2822 Sender If present there is no reason this should not be
consistent.
Non-compliant forwarders should get in compliance.
This, I'm not so sure about.
RFC2822 section 3.6.2. "Originator fields" says, in part, the following:
The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
Correct. There is no consistency here.
2822 From If Sender is not present then there is no reason this should
not be consistent.
I can't think of any problems with RFCs here, but I haven't pondered
things like multiple mailboxes on the From: header and the
relationship with the Sender: header and such.
Our SMTP design is based on RFC and BCP. We also try to follow what the
most popular systems do for consistency. Our system like most, if a FROM:
is missing, it is auto generated for the message. So I don't think you
will find systems wanting to reject mail at the DATA stage or POST SMTP
because the From: is missing. To illustrate my point, take a look at this
manual transaction:
Telnet mailc.microsoft.com 25
220 inet-imc-06.redmond.corp.microsoft.com Microsoft.com ESMTP Server Fri,
16 Apr 2004 15:42:34 -0700
HELO hdev1
250 inet-imc-06.redmond.corp.microsoft.com Hello [68.223.196.186]
mail from: <hsantos(_at_)santronics(_dot_)com>
250 2.1.0 hsantos(_at_)santronics(_dot_)com(_dot_)(_dot_)(_dot_)(_dot_)Sender OK
rcpt to: <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com>
250 2.1.5 hkatz(_at_)exchange(_dot_)microsoft(_dot_)com
data
354 Start mail input; end with <CRLF>.<CRLF>
hi harry,
this is a test of no headers!
.
250 2.6.0
<INET-IMC-06lEuef4wv0003add1(_at_)inet-imc-06(_dot_)redmond(_dot_)corp(_dot_)microsoft(_dot_)com>
Queued
mail for delivery
This is common.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com