Re: draft-lilly-from-optional-01.txt

Charles Lindsey <[email protected]> writes:
> Russ Allbery <[email protected]> writes:

>> What do you mean by "altogether breaks"?  It looks to me like it causes
>> sendmail to corrupt the message by introducing a spurious From header
>> with no actual content (a bug in sendmail, IMO, as an MTA should not be
>> modifying even messages that it deems syntactically invalid), but that
>> seems a far cry short of "altogether breaks" and just would put
>> sendmail into the class of programs that don't correctly comply with
>> this draft.

> Not sure what you mean by "a spurious From header with no actual
> content".  It most certainly did have a content (my own mailbox, as it
> happens).

Yeah, that was ambiguous.  I meant that it contained no useful semantic
content that wasn't already available, not that the header was completely
empty.

> Yes, it may well be regarded as a sendmail bug, but it is so widely
> deployed that it cannot be ignored. And if sendmail contains that bug,
> who is to say what other systems (e.g. exim) have fallen into the same
> error.

I get all of that.  It doesn't bother me, frankly; whenever any
modification is made to a standard in the area of previously undefined
behavior, some existing software isn't going to be immediately up-to-date.
sendmail has for years violated many existing best practices for MTAs, and
it shouldn't be at all surprising that it doesn't support new drafts that
depend on those best practices.

What I'm trying to understand is where you came up with "altogether
breaks," which would indicate some sort of interoperability issue or some
sort of break with backward compatibility that would mean that Bruce's
draft would cause systems not to interoperate in practice.  I'm still not
seeing where you saw that problem.  Could you please fill us in?

> He claims that it will do no harm to the existing network. We already
> have one counter example to that,

We do?  Please, by all means, fill us in!  Or do you consider addition of
a spurious header by sendmail to be harm, in which case I'm completely
mystified by the definition of harm that you're applying?

If you consider modification of a message in ways not covered by RFC 2822
to be harm, sendmail is already routinely causing harm via its behavior of
rewriting From, To, and Cc headers to canonicalize CNAMEs and corrupting
messages by adding spurious "Undisclosed recipients" headers.  This is
certainly no worse.

> Who knows? It might not even get through the mailing list expander.

I expect it probably wouldn't if the mailing list expander refuses mail
from unknown senders, which would most certainly include anonymous
senders, but that's not an argument against Bruce's proposal.  It is,
rather, a quite reasonable effect of local filtering configurations.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>