On 6/30/19 10:51 AM, Martin Gregorie wrote:
If you don't mind a delay in receiving mail from hosts you've never seen
before, why not implement a greylister?

https://en.wikipedia.org/wiki/Greylisting

I see your GreyListing and raise you NoListing:

https://en.wikipedia.org/wiki/Nolisting

TL;DR: NoListing works by having an MX record that either does not respond to TCP connections for SMTP, or sends TCP Resets. Thus causing RFC compliant DNS servers to move on to the next priority MX in short order.

I find that this cuts out a LOT of crap without most (if not all) of the problems generally associated with GreyListing.

 · It's stateless
 · It doesn't care where the retries come from
 · It's RFC compliant, no grey area
 · It allows fast retries.
    · Nothing prevents the same server from trying the next MX immediately.
 · There aren't issues with "You must wait X number of minutes".
    · There is no mechanism in SMTP to indicate how long to wait.
    · Servers can try the next MX immediately

I also highly recommend something like Junk Email Filter's Project Tar(baby) as a high order MX.

Link - Project Tar
 - http://wiki.junkemailfilter.com/index.php/Project_tarbaby

While you're at it, consider using Junk Email Filter's Spam DNS Lists to filter bad actors learned via Project Tar.

Link - Spam DNS Lists
 - http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists



--
Grant. . . .
unix || die

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to