[spambayes-dev] sb_mailsort.py status

[T. Alexander Popiel]

In message:  <MHEGIFHMACFNNIMMBACAKEIMJEAA.sethg at GoodmanAssociates.com>
             "Seth Goodman" <sethg at GoodmanAssociates.com> writes:
>> From: T. Alexander Popiel [mailto:popiel at wolfskeep.com]
>> Sent: Monday, January 10, 2005 4:36 PM
>
><...>
>
>> Unfortunately, bouncing spam after acceptance is increasingly unavoidable
>> for anyone who has a backup MX host as insurance against their primary
>> host being down.

[...]

>It is perfectly reasonable to establish a secondary in another facility that
>still has the same list of real mailboxes and the same incoming policy as
>the primary.  This might rule out some providers of backup MX services, but
>not all.  If you're a large operation, you should have complete control over
>your secondary.  If you're a small operation, you might want to rethink if
>it is really necessary to have a secondary MX if it is not possible to clone
>the setup of your primary.  Hardware and network connections are more
>reliable than they used to be and senders will queue your mail upon
>temporary failures.

I'm an extremely small operation... this is my home box, maintained
in my spare time, and I trade secondary MX services with friends
on multiple continents.  Yes, I could export my list of valid addresses
to said friends, but it would still be a hack to the mail server to
obey that list for relay (unless I'm missing something in the postfix
docs, which is entirely possible).

>> When the primary then rejects the message from the
>> secondary, the secondary is stuck trying to deliver a DSN.
>
>This is exactly the situation you never want to be in.  A spammer should get
>the same rejection at your secondary that they get at your primary.

In a world of robust communication between primary and secondary,
yes... but that requires much more investment in the infrastructure
than I've had opportunity to make.

>> (These spam DSNs frequently end up deferred because the purported
>> source either doesn't exist or issues a 400-series response to
>> trying to deliver the DSN... and the retries of these deferrals for
>> 4 days is what pushes my secondary over the edge.)
>
>Another possibility is that the systems to whom you are sending bogus DSN's
>are teergrubing you (forcing you to keep a socket and process alive for a
>long time) as punishment for abuse.

1. The DSNs are not bogus; it's the messages that they're in response
   to that were bogus.

2. Since it's disk space that's the problem and not CPU time, teergrubing
   is not an issue.  (My home DSL link (or that of my secondary) isn't fat
   enough for it to be worth teergrubing me, anyway.)

3. It's unforunate when obeying the RFCs is considered abuse.

- Alex