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): [EMAIL PROTECTED] Jabber: Because it's time to move forward http://ursine.ca/Ursine:Jabber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
