Qmail
[Top] [All Lists]

Re: Advanced tricks I use to get rid of spam using MX 4xx

To: dl@blackpacket.net
Subject: Re: Advanced tricks I use to get rid of spam using MX 4xx
From: Uncle George <qmail@gatworks.com>
Date: Mon, 27 Nov 2006 18:57:37 -0500
Cc: qmail@list.cr.yp.to
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
In-reply-to: <456B6BCE.1030409@blackpacket.net>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <45676987.2050808@perkel.com> <456789E5.3000508@gatworks.com> <20061125.101809.193764004.hanche@math.ntnu.no> <45686D69.5040003@perkel.com> <20061127143127.GA29898@discworld.dyndns.org> <456B03BA.1060303@perkel.com> <456B5418.10708@blackpacket.net> <456B5AE9.9060402@gatworks.com> <456B6BCE.1030409@blackpacket.net>
User-agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)


Some people think this should mean:
-> TRY1: "MX5 is dead, MX10 is greylisting, MX15 is greylisting, MX20 is greylisting" -> TRY2: "MX5 is dead, MX10 accepts message"

While QMail thinks this should mean:
-> TRY1: "MX5 is dead, MX10 is greylisting"

u really mean:
TRY1: "MX5 is dead, MX10 is greylisting, MX15 dont bother, MX20 dont bother"

-> TRY2: "MX10 accepts message"

Is there a reason to go onto MX15 or MX20? MX10 says that it'll accept the mail, but that it's temporarily unable to do so. Trying the other MXes just generates additional unnecessary traffic.

Yes, maybe MX15 will accept the message! Maybe MX20 will accept the message. You wont know till you try.

As the original poster stated, a long time ago, his service greylist's everyone on the lowest MX. But apparently accepts, without greylisting, on the next MX. This on the presumption that spammers will only try the lowest MX, and ignore the higher MX's. Real MTA's, as per 2001 spec's, would have tried at least the 2 very lowest MX's, if not the preconfigured limit, or all of the MX's .

Its not for me to say what the reasons ( or reasonableness ) are for why this SMTP strategy is acceptable for some. Or even why such matters have to be codified in an RFC .

<Prev in Thread] Current Thread [Next in Thread>