[ On Tuesday, September 18, 2001 at 10:03:01 (+0100), Matthew Byng-Maddick wrote: ]
> Subject: Re: [Exim] Trying to compare HELO data with actual host info in a filter...
>
> > > b) the only kind of error response you can give to a legitimately formatted
> > > helo line is a 421, in which case dropping the connection is legitimate.
> > No, that's asking for very big trouble. Many (not so well programmed)
> > mailers will immediately connect back again, and will continue doing so
>
> Teergrube.
Response rate limiting is not a sufficient defense in this case. Some
remote mailers will not only connect back immediately anyway, but may
even do so dozens or hundreds of times, once for every message in their
queue.
If you don't want, or will not accept, the message then you MUST reject
it immediately with a 5xx response. Period.
> > for as much as an hour or more, and often will repeat this cycle again
> > and again after some intermediate period of inactivity. If you don't
> > have any delay to penalize such failed connections (i.e. before the 421
> > is issued) the effect can be very nearly a DoS against yourself!
>
> I do, see above. I agree that this is potentially a bad thing, but on the
> other hand it's the only valid response you can give to a correctly formatted
> HELO.
NO! That is flatly wrong. 550 *is* a correct response in these
circumstances. In fact in this particular case any 55x number is the
most appropriate response.
> > It's also very inconsiderate to a legitimate sender. Their e-mail will
> > now sit in their mailer's queue until it either bounces after N days of
>
> Yes... and? Their mailers queue will probably send them status notifications
> too.
Not all mailers send timely status notifications.
> > attempts, or until manual intervention is taken. Never return a 4xx
> > series response if your intent is to reject the message or the
> > connection. It will not work and it can only cause problems at both
> > ends.
>
> No. You *aren't* allowed to reject based on the HELO parameter. RFC1123
> makes this clear. So does RFC821.
WRONG WRONG WRONG WRONG WRONG WRONG WRONG!!!!!!!! Your understanding of
SMTP is quite flawed it seems. Perhaps this selected quotation will help:
RFC 821
APPENDIX E
Theory of Reply Codes
The three digits of the reply each have a special significance.
The first digit denotes whether the response is good, bad or
incomplete. An unsophisticated sender-SMTP will be able to
determine its next action (proceed as planned, redo, retrench,
etc.) by simply examining this first digit.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (2821 is just a PROPOSED STANDARD, and
> hence shouldn't be referred to).
You apparently have a *LOT* to learn about reading RFCs and interpreting
them in general. From RFC 2026:
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
RFC 821 is not actually an IETF/IESG standard. STD 10 has been removed
and is reserved for the next approved SMTP standard (and currently
reference has been made explicitly to RFC 2821). Same with RFC *822.
From std-index:
0010 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format:
TXT=120432 bytes) (Obsoletes RFC788, RFC780, RFC772) (Obsoleted by
RFC2821) (Also RFC0821)
0011 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. D.
Crocker. August 1982. (Format: TXT=106299 bytes) (Obsoletes RFC733)
(Obsoleted by RFC2822) (Also RFC0822)
and from STD 1 (aka RFC 2800)
SMTP [Reserved for Simple Mail Transfer Protocol (SMTP). 10*
See RFC 2821.]
SMTP-SIZE SMTP Service Extension for Message Size Declaration 1870 10
MAIL [Reserved for Internet Message Format. See RFC 11*
2822.]
It is likely that RFC 2821 will become STD 10 when it makes its way
through the remainder of the standards process.
> This is true, however, you should be aware of Jon Postel's:
> "Be conservative in what you send and liberal in what you accept".
> Reread the first part of that sentence. Several times.
You realy do have an enormous ammount to learn about reading and
interpreting IETF documents.
You also apparently have a lot to learn about communications protocols
and where to draw the line between protocol robustness and absolute
stupidity.
Protocol robustness deals with making the lexical and syntactical
analysis of the protocol resistant to minor and irrelevant variances so
that they do not cause communications to break down. It has nothing
whatsoever to do with interpreting the semantics of protocol elements,
and certainly nothing to do with accepting all e-mail regardless of
local policy.
The RFCs are, obviously, not perfect. For example the second paragraph
of RFC 1123 5.2.5 clearly violates the robustnes principle by insisting
that policy matters be ignored. Clearly that paragraph must be ignored
by any modern SMTP implementation that takes local policy considerations
into account.
> This is kind of true, as long as you are using ESMTP and you've both agreed
> on extensions, otherwise you should really be using the table of defined
> responses in S4.3 of RFC821, or you are running a non-standards-compliant
> mailer, and just as guilty as the other party.
WRONG. See Appendix E of RFC 821 (the important bit is already quoted
above). There has NEVER been any restriction on the exact set of
response codes allowed in SMTP. PERIOD. The ONLY part of the response
code that any receiver-SMTP can use to identify its next course of
action is the FIRST DIGIT of the response code. The other digits are
simply informational. This is clarified and reinforced in RFC 2821
(which obsoletes RFC 821).
> I don't think you can define the behaviour of sending a 5xx class error at
> HELO time, other than for a missing parameter.
Look I've been doing this stuff for *YEARS* now. I know very well what
I'm talking about.
> Should I retry, obviously
> not, what should I put in the bounce?
You can put anything you want in the bounce. You probably should
include any response text recieved of course.
> Oh? Most people I've seen just complain and whinge, and assume that
> a) they have a right to send me email
Nobody has the "right" to send me e-mail. That's a privilege that's
implicitly granted by me, and supported by my operation of my own
private systems connected through my Internet connection to the rest of
the world. I have the right to refuse any and all attempts to send me
e-mail.
> b) that if every other mailer works and mine doesn't, then there's obviously
> somethin wrong with mine rather than theirs...
Yeah, that kind of logic and a 25-cent coin will get you a phone call at
a pay phone in most of North America.
> > I never make any exceptions for problems that are not my own. If some
> > sender has a broken MTA or DNS configuration then they can fix it if
> > they want to send me e-mail.
>
> This attitude unfortunately doesn't work. Which is a pity.
I thin you need to re-read my message. My approach to this problem
definitely does work. It has worked in every single instance. There
have been no exceptions whatsoever. It is guaranteed to work, in fact!
You simply have to lay down the rules and if people really want to send
you e-mail they will fix their configurations whether they think it's
necessary or not. If they don't want to send you e-mail then you don't
have to worry about it.
> These days, rDNS
> is seen as a "security risk", no, I'm not joking, and I require rDNS in
> order to deliver mail to mbm@???.
Who said anything about rDNS? I sure as heck didn't.
Yes, some people consider it a risk. Obviously those people know very
little about the Internet and about security analysis in general.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <woods@???>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
