Re: regarding illegally formed address and commands

[Ned Freed <[e-mail]>]

> > Depends both on the command as well as what's illegal about it. As another data
> > point, PMDF will reject a command when the command syntax itself, as opposed to
> > the arguments to the command, is illegal. When an argument is illegal it
> > depends on what the argument is used for. In the case of a malformed address
> > argument to a MAIL FROM command, for example, PMDF doesn't care since it isn't
> > essential in getting a message delivered, and experience has shown that
> > rejecting such messages on the basis of a potential problem returning a
> > nondelivery notification later is not what users want.

> > PP, on the other hand, is much more picky about this sort of thing. I don't
> > believe it will let an invalid argument to MAIL FROM through at all.

> So the command is checked but not the parameters?

I said nothing of the sort. Read my response again, but this time read it more
carefully. I quite clearly said that it depends on what the parameter
information is used for. If for instance it is an envelope recipient, the
checks made a fairly rigorous, and end up catching all of your "illegal"
variants at the SMTP level.

In the case of a envelope originator, however, pretty much anything goes.

> Is this healthy?

15+ years of doing this stuff tells me that it is extremely healthy. Why?
Because the vast majority (and I do mean vast) of messages have valid recipient
addresses. Failing things on the basis of the validity of a field that is
almost always unused is just plain silly. Try explaining it sometime to a very
senior technical person at a large company who is trying to get some important
mail delivered whose return address is both bogus and unfixable. I have, and I
have watched entire product suites get summarily dumped as a result of such
discussions.

> Are there reasons that the parameter is not checked?  I mean if it
> gets the MAIL FROM address wrong, it cannot bounce the message back
> anyways.

So what?

> Um... actually, according to the RFC821 grammar (which we are all
> bound to until 821bis is finished), the domain part of the address
> itself is a series of parts, each separated by dots, with an
> alphabetic at the front; alphas, numerics, and a dash in the middle;
> and an alpha or numeric character at the end.
> i.e. a12.com is legal, as is a1-2.com, but 1.com, a1-.com, and -1.com
> are illegal... according to 821 at least.

I wasn't going by the RFC821 grammar, which I regard as hopelessly buggy and
totally unusable. In general I try to ignore RFC821 grammar to the greatest
extent possible and just use RFC822 instead.

Why do I always do this? Because a strict implementation of the RFC821 grammar
results in a system that's unusable in practice. For instance, if you consider
yourself bound to the RFC821 grammar that means you had better be rejecting any
domain name that contains an element consisting of less than three characters
that isn't a domain literal. This is obviously a nonstarter. You're also going
to lose badly should you attempt to depend on legal gunk in the RFC821 grammar
like the ability to use \ outside of a quoted string in a local part or the #
form of domain literal. Try stuffing the former into an RFC822 message header
and see what happens, and once you've finished that conduct a survey and find
out how many systems support the # literal form.

This isn't to say that RFC822 grammar isn't buggy. It is. It allows dreck like
"this is"."a legal"@address, which RFC821 doesn't. (This is about the only
RFC822 botch that RFC821 fixes, however.) But at least the RFC822 grammar
doesn't explicitly disallow a ton of forms that obviously should be allowed and
in fact must be allowed if we're to have an operational network.

As such, I essentially regard the RFC821 grammar as having been superceded by
that in RFC822, and when implementing I try to support as much of the
RFC821-specific stuff as possible but coerce it into a form that is compatible
with RFC822.

In any case, please don't try to tell me that the syntax specified in RFC821
should in any way determine what behavior is correct, because it just won't
wash. There are, however, plenty of other reasons you can use to say that funny
characters in the domain name of an envelope recipient address should cause it
to be rejected. For example, you could cite the domain registration rules
(which do restrict the repetoire) and then say that you tolerate no exceptions
locally under any circumstances, hence you are justified in rejecting them. Or
you could say that you reserve % specifically for use locally as a separator.
But these are both really rejections on the basis of assigned semantics, not
syntax.

				Ned