[ On Friday, December 5, 2003 at 14:42:54 (-0800), Pat Lashley wrote: ]
> Subject: Re: [Exim] cyrus NUL failures
>
> The biggest problem I've seen so far has been with messages that
> were relayed through mailing lists that don't enforce RFC compliance.
> I haven't seen any NULs through the lists; but I do see a trickle
> of unencoded 8-bit characters in headers.
This is probably a case where what you really want to do is to mangle
the incoming messages to remove or transform the offending 8-bit-high
characters. Personally I would just replace them all with underscores,
but perhaps you might want to translate them into octal or hex
representations of their values.
> Unfortunately, blocking
> them in ACLs tends to get me suspended from the list for excessive
> bounces without ever notifying the original sender of the problem...
Well of course! :-) You cannot have your cake and have eaten it too!
> I suspect you may be right; but I'm not yet willing to concede
> that a better solution isn't possible.
Well unless you're willing to manually contact the person(s) sending the
offending messages out-of-band, i.e. by telephone, postcard, etc., then
there really is no better solution possible, by definition of the way
the protocols work. You really cannot trust the sender address for the
purposes of generating a new bounce message in this kind of situation,
and even if you avoid creating a DoS monster by restricting bounces to
one per week per address you'll still highly annoy people should some
third party exploit this weakness in your system (and someone _will_
find and exploit it).
> >> (And, of course, some sort of tests to try to
> >> avoid sending to a mailinglist address.)
> >
> > These basic rules for any autoresponder should apply, at minimum:
> >
> > 1. No response should ever be sent _unless_ the recipient's mailbox is
> > part of either the ``To:'' or ``Cc:'' headers of the mail. This will
> > almost always prevent your e-mail autoresponder from replying
> > directly to a mailing list injection/posting address even if non of
> > the other remaining mechanisms prevent a reply.
>
> That depends on the mailing list mechanism; but it certainly does
> eliminate most of them.
Note these rules _must_ be all used together.
> > 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?
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.
> 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.
> 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.
> 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.
> 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.
> 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.
RFC 2047 is just a very recent new way to give users more flexibility
in headers without breaking the original rules. Users wanted this
flexibility because they'd come to expect it after having used MIME for
their message content.
MIME content encoding is another part of the toolkit that makes it
possible to use non-ASCII character sets in SMTP mail. Note that while
your local MTA might accept MIME parts with 8-bit-high characters the
goal of MIME is to make it possible for mail gateways to translate the
internal encoding of a message so that it can safely pass through MTAs
that would otherwise reject or trash 8-bit-high characters, or even to
translate to totally foreign character sets (e.g. EBCDIC)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
