[COLUG] another anti-spam link

[R P Herrold]

On Fri, 30 Nov 2007, Duane wrote:

> I can only think of one legit situation where bouncing would still be
> suitable, that is accepting and acting as a relay either the whole
> domain or just mail aliases where the remote end is down/rejecting your
> MTA from sending etc, everything else should be rejected at the
> pre-queue/pre-disconnection stage.

Bounces (if not capable of offer time deferrals or rejections) 
are legitimate and needful for RFC compliance.  If one 
does not care about meeting the standard, I guess 
that's OK, but if one starts toward such 
balkanization, where does one stop?

Consider multiple rotating subordinate boundry intake MX's 
(think: AOL: dig -t mx aol.com i  s instructive to think 
about).  AOL seems to put a cloud of boxes out (and one 
assumes when any given box gets 'full', removes it from the 
roundrobin DNS).  They _could_ know or do a LDAP query to 
determine the legitimacy of a given recipient, or the 
individually managed whitelists, blacklists, and so forth. But 
from observation, they seemingly just accept email and then 
pass it along to filtering processes.  If something along the 
way  don't like a given piece, delivery is completed for the 
disliked piece to /dev/null -- ugh.

A sender has a seeming acceptance, and no return -- AOL breaks 
the RFC, but that makes life manageable for AOL.  Of course 
the admin at the sending end gets the support call burden from 
its support tech, on behalf of the sender, and has to spend 
the time to trace the logs.  At the end of the eay, the 
support tech can only tell his sender -- 'they took it' and 
seem to have dropped it;  ask the recipient to check with AOL 
-- and that is the end of that, unless the recipient feels 
like wadeing through the muck of its upstream support ;)

Bugger your neighbor is wrong.

-- Russ Herrold