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: