[COLUG] another anti-spam link

[Duane]

R P Herrold wrote:
> 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?

I seemed to have over simplified things, I'm not talking about stopping
bounces, I'm talking about stopping servers that accept messages and
then send bounces when they could have easily rejected the messages
before accepting it.

Servers that do accept then bounce messages tend to flood the inboxes of
email servers listed as the from but had nothing to do with the email in
question.

As for your AOL example, rather then dumping the message to dev null,
they could should attempt delivery before accepting, and then either
accept or reject with a hard error, the end result would be the same for
them, or maybe they should just outsource to google too ;)

-- 

Best regards,
 Duane

http://www.freeauth.org - Enterprise Two Factor Authentication
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."