On Mon, 3 Mar 2003, Arnt Gulbrandsen wrote:
> >>   But I don't
> >>  see any obligation for MTAs or UAs to deal with whatever random
> >>  trash is thrown at them.
> > "Be conservative in what you accept" and all that, right?
> Ten or eleven years ago I was told (on ietf-smtp?) that I had
> misunderstood that stuff, and that it really had to do with RFC
> handwaving, not accepting clearly broken input.

I certainly agree with this.  The phrase was "be liberal in what you
accept, and conservative in what you generate."  It was certainly never
meant as license to commit crass violations of the specification.

The meaning is:

1) Accept the complete specification; don't take shortcuts in your parser
and assume that nobody will ever generate a particular syntax so you don't
need to implement it.  If parsing message headers, read the formal syntax
of RFC 2822 carefully and implement that; don't guess based upon sample
messages.

2) Avoid generating anything that isn't a commonly-used part of the
specification.  Assume that your output is going to be read by a baby
programmer's parser, and that baby programmers aren't going to know about
the more arcane parts of the specification.

Nothing here has anything to do with "accept any sort of broken input
provided by a baby programmer."  Rather, it has to do with focusing upon a
subset of the specification that even a baby programmer can get right, and
leaving the arcane details for consenting adults.

Sometimes, it is desirable to be quite uncompromising when detailing with
baby programmers.  In particular, those of us who have SMTP servers that
insist upon proper CRLF newlines notice much less spam than users of
sendmail, etc.  That is because most spamware sends UNIX-style LF-only
newlines; a common baby programmer mistake.  Most legitimate SMTP software
trips up on an interoperability problem, the bug is presently fixed, and
the baby programmer becomes a toddler programmer.  Spamware on the other
hand isn't fixed, because it disregards communications problems in the
name of not delaying the spam run.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Reply via email to