Re: [Exim] cyrus NUL failures

Pàgina inicial
Delete this message
Reply to this message
Autor: Exim User's Mailing List
Data:  
A: Pat Lashley
CC: Exim User's Mailing List
Assumpte: Re: [Exim] cyrus NUL failures
[ 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.

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.

> 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.

> (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.

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).

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.

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''!

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.

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.


> 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.

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.

--
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>