Re: minimizing bandwidth taken be spam delivery attempts even when identifiable by "To:" address
Paul Johnson wrote:
On Wednesday 15 February 2006 09:58, Daniel B. wrote:
...
How hard is it to refuse incoming TCP connections to the SMTP port
based on DNSBL, using exim4?
That is easy, and I run my own DNSBL instead of trying to figure out exim4's
ACLs in great depth.
Would refusing connections reduce the
overall traffic (maybe even causing spammer machines to think I no
longer run an SMTP server?)?
Yes, it will reduce traffic by rejecting the message before DATA.
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"))).
> 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?.
I was talking about what the spammer would do if it got "connection
refused" when trying connect to my SMTP port:
Or do spammer machines usually check
DNS MX records and would they deliver mail to the backup mail server,
which would then try to deliver it, using up the same bandwidth?
Well, whatever method you use to filter email should be used on all your
inbound MXs, or you're just defeating your own efforts.
Okay, thanks for confirming my impression there.
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.)
Daniel
Reply to: