[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: minimizing bandwidth taken be spam delivery attempts even when identifiable by "To:" address



Reply-to-all violates Debian list rules.  Please use reply-to-mailing-list 
instead.

On Wednesday 15 February 2006 13:26, Daniel B. wrote:
> Uh oh; it sounds like you weren't paying attention to my question.
>
> I wasn't talking about rejecting _messages_; I wa talking about
> rejecting TCP _connections_, somehow injecting blacklist checking
> between receiving a TCP SYN(?) packet and replying (either accepting
> the connection or refusing it (generating "connection refused"))).

This is not the answer you are looking for.  You also need to consider false 
negatives:  Don't make it impossible for a real human to troubleshoot a 
problem with email.  Obfuscating the rejection serves only as a stumbling 
block for real humans, not spammers.

>  > No, the
> >
> > spammer won't think you no longer run an SMTP server because that assumes
> > spammers care about delivery notifications (a fact not in evidence).
>
> Yep, you weren't paying attention:  How would delivery notifications
> be relevant?  If I don't even accept the TCP connection, there's no
> SMTP conversation, so there's no delivery notifiation to talk about,
> right?.

Either accept the connection globally or deny it globally for email.  If you 
need anything more refined than that, it needs to happen at SMTP time, not 
before, not after.

> >>Is rejecting the message at the RCPT command the best action, or
> >>is something else better?
> >
> > Any time during the SMTP connection is a good time.
>
> Not if I'm trying to minimize bandwidth.  (Rejecting right after
> recognizing a bad address is clearly better than receiving a whole
> message.)

It sounds like you're already at a spot where you can't reasonably reduce 
bandwidth used by email any further.  Consider reducing bandwidth usage 
elsewhere.  For example, does your network have a caching HTTP proxy?  If 
not, you're literally flushing bandwidth down the toilet.  Most organizations 
have far, far more to gain from caching HTTP than from cutting corners on 
email.

-- 
Paul Johnson
Email and IM (XMPP & Google Talk): baloo@ursine.ca
Jabber: Because it's time to move forward  http://ursine.ca/Ursine:Jabber



Reply to: