--On Saturday, December 06, 2003 14:20:09 -0500 "Greg A. Woods" <woods@???> wrote:
>> > 2. No response should be sent to messages from ``-OUTGOING'',
>> > ``-RELAY'', ``LISTSERV'', ``-REQUEST'', ``MAILER'', or
>> > ``MAILER-DAEMON'' (where these strings are case insensitive suffixes
>> > of the base mailbox name (local part) of the sender or originator
>> > address, and should match any and all domains).
>>
>> Nor to '*-BOUNCES*' nor '*<recipient localpart>=<recipient domain>'.
>> (Both common in VERP-based mailing list bounce handling.)
>
> Any list using a sender address of "*-BOUNCES" is stupidly incompatible
> with the rest of the world. Can you identify any software that uses it
> by default?
It seems to be the standard form for mailing lists that use VERP
addressing. Note that I had an asterisk after 'BOUNCES'; and that
in the examples I've seen the two cases I listed above are redundant.
> As for trying to handle VERP-based sender addresses, well good luck.
> You'll fail far more often than you succeed! You can do no better than
> play a game of catchup.
What is your basis for that contention? Do you know of any mailing
lists that use VERP but don't use the '*<localpart>=<domain>@...' form?
In any case, it is no more of a game of catchup than any other aspect
of attempting to recognize that the sender is a mailinglist address.
>> 5. No reply should ever be sent to a message with a 'List-*' header.
>
> Nope, that's not true. List messages can be resent without stripping
> those headers. List-* headers do not prove that the message was
> received directly from a list expander.
In this case, I believe the consequences of a false positive are much
less sever than those of a false negative.
>> Actually, that's not a strictly accurate representation of the situation.
>> RFC 2047 provides a mechanism to encode -any- character set into a header.
>
> True enough -- but that's irrelevant. The point is to prevent all
> characters outside the standard ASCII printable characters. Using RFC
> 2047 encoding is simply one of the ways of doing that, but not the only
> one, and certainly not the obvious one.
I was just trying to clarify the situation for anyone else who is
following this thread. We are in fundamental agreement on the reasoning.
>> Cyrus deals perfectly well with properly encoded character sets.
>
> Cyrus IMAPd doesn't care -- it only cares that only ASCII characters are
> used in RFC [2]822 headers. The rest is up to the MUA.
Exactly. That's what I was saying.
>> It is,
>> however, the only mail handling system that I am aware of that enforces
>> the encoding requirement.
>
> Cyrus IMAPd is far from alone in "enforcing" character set rules --
> though the others are now far more rare and Cyrus is perhaps unique in
> that, IIRC, it only concerns itself with message headers.
As I said, it is the only one that I am aware of. I didn't mean to
imply that it is the only one that exists. (In fact, I'm somewhat
in favor of their strict compliance rules and would like to see them
implemented widely enough to force vendors to fix broken MUAs.)
>> The reasons for this enforcement are quite
>> likely, as you say, primarily to improve communication among people using
>> different character sets. But then that was the reason for the RFC
>> 2822 restriction and 2047 encoding extension in the first place...
>
> Well, actually _all_ SMTP traffic is restricted to ASCII character sets
> and always has been -- i.e. it's been that way for over 20 years now,
> right from day one, and don't expect that to ever change.
I was under the impression that the 8BITMIME extension had relaxed
that to allow message bodies with almost any octet to be passed
unencoded. (Obvious exceptions including NUL, CR, and LF.) Assuming,
of course, that both ends of the transfer support it.
-Pat
