--On Saturday, 17 August, 2002 13:04 -0500 "Eric A. Hall"
<ehall(_at_)ehsco(_dot_)com> wrote:
on 8/17/2002 12:54 PM Arnt Gulbrandsen wrote:
You most certainly are allowed to reject connections from
www.spammer.com.
You can reject the connection because the SMTP client's IP
corresponds to www.spammer.com. Perfectly legal by the RFC.
The HELO/EHLO argument never enters the picture.
I'm aware of that, but it's not what I'm asking about. I'm
specifically asking about using the EHLO identifier as a
policy trigger. Under the interpretations of the section as
provided here, this is prohibited.
--On Saturday, 17 August, 2002 11:53 -0500 "Eric A. Hall"
<ehall(_at_)ehsco(_dot_)com> wrote:
ps--according to the statements made here, I am not allowed to
filter based on a HELO identifier which has verified in the
positive form, either. EG, I'm not allowed to reject sessions
from spew.spammer.com, even if I know with certainty that the
identifier is correct.
So, clarification on allowable policy when verification
succeeds is what I'm after, although frankly, I don't know why
2821 addresses policy issues at all.
Eric,
Speaking as the victim^H^H^H^H^H^H editor, this sort of stuff is
one of the things that caused DRUMS to take as long as it did
and that is causing motivation problems with a revision to 2821.
The sequence of events is that someone reads something into the
text that isn't there (usually omitted quite deliberately).
Then people comment on the subject, usually on the matter of why
the text is really quite specific and adequate, even if it could
be better written. After the discussion goes on for a while,
and more misinterpretations are posted, it becomes clear that
the text should be clarified to eliminate any ambiguity. So,
someone, usually the editor but ideally someone else, suggests a
patch and, often because everyone is tired of the discussion by
that time, the patch is accepted by general silence and
indifference. It then goes in, and, by further complicating
things, creates an additional opportunity for readings that were
never intended. I don't know how to fix that, and it is clearly
why we pay WG Chairs and editors the big bucks, but...
To repeat what others have said, the text you cite, as it now
appears in the middle of section 4.1.4, does not prevent you
from looking at the argument to EHLO (or HELO) and immediately
generating a 550 response. It is addressed to one case only,
which is your mapping a FQDN you find there to an IP address (or
determining the IP address by some other mechanism), then
determining whether the IP address is that of the proported
client, and then rejecting the message if it does not, _because_
it does not. And, as others have pointed out, the main reason
for that prohibition (which comes from RFC 1123) is that the
behavior is dumb.
To say this again in other words, that paragraph doesn't
prohibit you from rejecting a session from spew.spammer.com,
either by determining that you don't like the string, or by
noticing that the IP address is that of a known spammer
(regardless of whether it matches the EHLO argument string or
not), or by some other method. It just doesn't address those
issues.
Those issues _are_ addressed in section 7.7, which gives fairly
broad latitude for SMTP servers to be configured to reject
problematic traffic while still conforming to the standard.
And the latter is the reason why 2821 must "address policy
issues". If standards are to be useful, it is important, IMO,
to be able to make meaningful statements about whether something
conforms to them or not. And that, in turn, makes it important
to distinguish between non-conforming behavior and behavior that
is consistent with adoption of policies that are sensible and
necessary under various conditions. Policy decisions permit
you to reject, implementations must have ways to not reject,
and, if you reject, the standard specifies that you use a 550
code.
If anyone has textual suggestions that would make this more
clear and less convoluted, I'm listening. Otherwise, can we
bury this particular dead horse.
john