--On Friday, December 05, 2003 16:53:19 -0500 "Greg A. Woods" <woods@???> wrote:
> [ On Friday, December 5, 2003 at 11:19:55 (-0800), Pat Lashley wrote: ]
>> Subject: Re: [Exim] cyrus NUL failures
>>
>> I am fully aware of these issues. That's why I have my ACLs set up
>> to try to reject messages at SMTP time rather than bouncing them later.
>> It's a big part of why I haven't taken the notification approach to
>> NULs yet.
>
> Thats good! ;-)
>
> Note that blocking incoming messages immediately during the initial
> stages of the SMTP transaction _should_ give an adequate explanation to
> the sender regarding the reason for the rejection (assuming your ACLs
> emit a useful SMTP response). I.e. you're (probably) already giving the
> best possible notice, in the most efficient manner, to the best
> identifiable sender, as to the reason for the reject.
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. 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...
> Any attempt to generate a new message in response (and use the SMTP
> envelope sender address to route it) can only be less successful, and
> potentially more dangerous (to innocent third parties) than what you're
> already doing.
I suspect you may be right; but I'm not yet willing to concede
that a better solution isn't possible.
>> If I ever do, it will only occur when the IP address of
>> the host that delivered the message matches up with the domain of
>> the envelope sender.
>
> Note that there's no defined relationship between the source IP address
> of the sending client and the domain in the SMTP envelope sender
> address. Pretending that there is will either make your test far less
> useful than you think it is, or may even lead you into trouble.
I know. But making that check will help to prevent some of the
'dangerous to third parties' issues that you are concerned about.
(At the expense of leaving some offenders un-notified.)
>> (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.
> 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.)
> 3. No response should ever be sent to the same address within some
> decent length of time, such as a whole week, i.e. seven full days.
> This will prevent mailer loops from becoming denial of service
> attacks and will also help prevent annoying human readers who don't
> need instantaneous reminders of your status every few moments.
I probably would have made that rule #1...
> 4. Finally, and most importantly, no reply should ever be sent if a
> ``Precedence:'' header is found which contains the value ``bulk'',
> ``list'', or ``junk''!
Yep, some mailing lists actually use those.
5. No reply should ever be sent to a message with a 'List-*' header.
> If you follow the above rules you will not have to teach your e-mail
> autoresponder about every possible mailing list you or your users might
> subscribe to.
But you should still be prepared for the possibility of having to
teach it about some abberant mailing list(s) if something turns up.
> As to who the message is sent to, well that depends on what is sending
> it, and why. In your case you'd only ever use the SMTP envelope sender
> address since your autoresponder is reporting mail transport issues,
> however any MUA-level auto-responder, such as an external "vacation"
> program, must only use the address(es) from the RFC-[2]822 reply fields
> ("reply-to:", or if none then "from:") since those are regarding content
> related issues, not delivery issues.
Right.
>> They are also strict about the RFC requirement that all octets in
>> the header block be in the range 1..127.
>
> Again this has _far_ more to do with practical reasons than RFCs, though
> of course it is no small coincidence that the RFCs say what they say.
Exactly. The rationale used by Cyrus strongly parallels that of
the RFCs.
> A single Cyrus IMAPd instance is often used by many diverse people using
> many different character sets, and often those people will need to
> communicate amongst themselves. It is parmount that they be forced to
> use only the least common denominator character set (ASCII) in the most
> critical parts of their messages (the headers), as otherwise only
> confusion and annoyance can result.
Actually, that's not a strictly accurate representation of the situation.
RFC 2047 provides a mechanism to encode -any- character set into a header.
The issue with non-encoded 8-bit characters is that there is no way to
tell -which- character set they belong to. (Which is why headers with
unencoded 8bit chars can't simply be fixed by the MTA or MDA.)
Cyrus deals perfectly well with properly encoded character sets. It is,
however, the only mail handling system that I am aware of that enforces
the encoding requirement. 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...
-Pat
