----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, June 20, 2005 1:10 PM
Subject: Re: SMTP Mail Hosting and TMS Recommendations [was: Hector's BCP
summary outline for SMTP]
[unnecessary meaningless comments removed]
SMTP servers SHOULD publish an extended line 220 greeting response
indicating the system server basic mail policy.
1. The SMTP protocol is based on reply codes; text is meant for humans
(RFC 2821 sections 4.2, 4.3). The protocol is based solely on the
reply codes, not on text.
Bruce, what was stated in no way implied the response codes were used to
define a policy. In fact, I stated a specific 220 reply code, no other was
stated.
What was missing from section 1.2 was that extended greeting responses deals
with addressing non-compliant SMTP bulk mailers who don't know handle
multiple line responses.
Try it. You should expect at atleast a 12-20% drop on Bulk Mailer spams.
5. In particular, any extension to SMTP involving negotiation (e.g.
of language for text) has to take place using the established ESMTP
negotiation mechanism.
Don't apply since you mis-understood the extended line 220 greeting response
statement. Same with comment #6 thru #8
Due to the nature of SMTP, HELO/EHLO validation is relaxed and its
verification is weak. There are legitimate reasons as to why a
client machine domain does not match the IP address.
So there are "legitimate reasons ..." (agreed), but it SHOULD
nevertheless
be checked. Why? And since (because of the "legitimate reasons") the
check provides no useful information, what is to be done with the results
of the "validation check"?
As recommendation stated in section #2 HELO/EHLO, you should perform first
syntax checking, possibly domain literal check and a lightweight LMAP local
domain spoof check.
Example:
CLIENT IP ADDRESS: 1.2.3.4
HELO mail.winserver.com
Since we have 100% of our local domains, it is illegal to use this domain
with an unknown IP address.
Try it. You will see a near 10-12% spoof trap.
I don't recommend at this point to this on an open ended basis for client
domain names simply because you dont' have control of remote domains used.
The overhead is too high and the reliability of the remote domain check is
not solid proof. The compromise is to perform it on the domains you do
have control over, this can include a database of domains you may have and
wish to spoof-trap.
Therefore, the SMTP server SHOULD highly consider to perform some
form of return path validation. How this is done is a SMTP system
implementation dependent and considered as a "BLACK BOX"
concept and is subject to on going R&D.
No. It is known that some hare-brained schemes are harmful (e.g. issue
a test message using a server specified as an MX host for the MAIL FROM
domain (if not a null reverse path); hint: consider what happens if both
servers do that). No "R&D" is needed to see that some schemes are
harmful.
That's your opinion, and I 100% sincerely respect it. But it is clearly not
the world consensus and the world should not be deemed idiots by you if you
disagree.
You should research the implementations before making unwarranted comments.
I stated it as a BLACK BOX because there isn't yet a universal method yet to
validate the specific process entity - 2821.Mail From:
Specifically, we use various BLACK BOX schemes, include SPF and CBV. The
CBV happens to be a very good concept and essential part of our system. It
is rapidly growing and in use by other SMTP vendors and ISPs.
The key fact is that that MAIL FROM is a verifiable item by RFC standards
and today, the CBV is the only way to do that.
Anyway, if this is all you really have to comment on, then I think it is
pretty good. As it should be, because its been implemented for nearly 2
years on commercial systems with high success.
I appreciate your comments.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com