[spambayes-dev] sb_mailsort.py status

[T. Alexander Popiel]

In message:  <20050110224442.GB1491 at mems-exchange.org>
             Neil Schemenauer <nas at arctrix.com> writes:
>On Mon, Jan 10, 2005 at 02:35:39PM -0800, T. Alexander Popiel wrote:
>> When the primary then rejects the message from the secondary, the
>> secondary is stuck trying to deliver a DSN.
>
>You really should not generate DSNs, IMHO.  They will very likely be
>sent to forged From addresses.  In that case, they are as bad as
>spam.

RFC 2821 requires DSNs if a site has accepted a message that is
subsequently discovered to be undeliverable:

# If an SMTP server has accepted the task of relaying the mail and
# later finds that the destination is incorrect or that the mail cannot
# be delivered for some other reason, then it MUST construct an
# "undeliverable mail" notification message and send it to the
# originator of the undeliverable mail (as indicated by the reverse-
# path).  Formats specified for non-delivery reports by other standards
# (see, for example, [24, 25]) SHOULD be used if possible.

Personally, I'm not willing to allow other people's anti-social
behavior to induce me to violate clearly specified standards.

>> PS. No, I'm not willing to not have a secondary MX.  My primary does
>>     crash occasionally, though (thankfully) not as much as it used to
>>     before I replaced the motherboard.
>
>I don't see how that makes a secondary MX necessary.  The sending
>servers have outgoing queues and they will retry.

Not all senders have outgoing queues (in particular, some mail clients
insist on trying to send mail direct to the destination, and have no
facility to queue until the destination is available).  Moreover, there
are times when my machine has been down for several days with hardware
failures, and while I can control the queue expiry on my secondary MX
(setting it to 30 days or so, when I know I'm going to be down a while),
I cannot control the expire times on any sender's queues.

- Alex