Having said all that, I would say that rejecting mail with unquoted dots
is completely reasonable, and is the best way to make sure that such
errors get caught sooner rather than later... -- Nathaniel
I think this is the crux of the argument we see going on here. I'm a
long-standing believer in this sort of position--that, if we were a lot
more aggressive about rejecting of bogus stuff, errors would get caught,
software would be fixed, and we would have a lot fewer interoperability
problems all around. As a statement of principle, people like Ned and
Mark probably agree with that statement.
But what I've gradually become convinced of is that the principle is
almost irrelevant. The pressures on a mail receiver to "get the mail
through regardless", to "fix it somehow and deliver it" are immense.
Ned and others have explained the issue in terms of people being told by
their bosses "I don't care what the standard is, fix the code to accept
this or I'll find someone who will". Those are *real* persuasive
arguments; they don't yield to principles of purity, etc.
If one cannot get an agreement from every significant MIME-receiver, now
and in the future, to reject -- note that this problem has to be noticed
and rejected down in the UAs, since there is, in general, no MTA clue
that the separators are bogus -- then some will accept, and the fact
that they accept will gradually turn into an oral tradition that this is
ok, and then pressures to accept will escalate.
Consequently, I think we are obligated to either
-- Come up with, and document, a Real Good Reason while dots have to
be on the list, a reason that is persuasive enough that no one really
tries this (or is quick to admit that they have a bug if they do).
-- Change the rule.
As I said earlier, I think I have a preference for the latter in terms
of parsimony of things that get quoted, but it is not a strong
preference. I do prefer that we not depend on principles that we
probably can't translate into reality in order to have good
interoperability.
--john