On Sun, Jun 07, 2020 at 05:53:28AM -0700, John Pierce wrote:> On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs <info at microlinux.fr> wrote: > > > .... > > My aim is simply to eliminate as much spam as possible (that is, before > > adding > > SpamAssassin) while keeping false positives to a minimum. > > > > The one thing that stopped the most spam on my last mailserver was > greylisting. Any mta that connects to you to send you mail, you check > against a white list, and if they are not on it, you reject the connection > with a 'try again later' code and add them to a grey list that will let > them in after 10 minutes or so. The vast majority of spambots don't queue > up retries, they just move on to the next target. > > The downside of greylisting is delayed delivery of mail from non white > listed servers, dependent on their retry cycle.I hit another limitation. My backup MX handler is a 3rd party who will not use greylisting. Thus all the 1st timers I rejected just delivered to my alternate MX address and were not blocked at all. Jon -- Jon H. LaBadie jcu at labadie.us
yeah, then don't use a backup MX server at all. I dropped using one when I realized most spam prevention would just end up at the backup which didn't have the same rules as long as your server has a decent uptime and is never down more than a few hours and that very rarely, then you really don't need a backup server at all. On Mon, Jun 8, 2020 at 7:57 PM Jon LaBadie <jcu at labadie.us> wrote:> On Sun, Jun 07, 2020 at 05:53:28AM -0700, John Pierce wrote: > > On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs <info at microlinux.fr> wrote: > > > > > .... > > > My aim is simply to eliminate as much spam as possible (that is, before > > > adding > > > SpamAssassin) while keeping false positives to a minimum. > > > > > > > The one thing that stopped the most spam on my last mailserver was > > greylisting. Any mta that connects to you to send you mail, you check > > against a white list, and if they are not on it, you reject the > connection > > with a 'try again later' code and add them to a grey list that will let > > them in after 10 minutes or so. The vast majority of spambots don't > queue > > up retries, they just move on to the next target. > > > > The downside of greylisting is delayed delivery of mail from non white > > listed servers, dependent on their retry cycle. > > I hit another limitation. My backup MX handler is a 3rd party who > will not use greylisting. Thus all the 1st timers I rejected just > delivered to my alternate MX address and were not blocked at all. > > Jon > -- > Jon H. LaBadie jcu at labadie.us > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- -john r pierce recycling used bits in santa cruz
On 9/06/20 2:56 pm, Jon LaBadie wrote:> I hit another limitation. My backup MX handler is a 3rd party who > will not use greylisting. Thus all the 1st timers I rejected just > delivered to my alternate MX address and were not blocked at all.Don't use a backup MX, they are a relic of the 90s when mail servers were often times not always online. a sending mail server will generally retry the message for up to five days if your MTA is down so backup MXes are really not necessary. As you have discovered, if you do decide to use a backup MX it really needs to have exactly the same anti-spam protections as the primary MX, but most backup MXes don't and spammers know this. In fact many spammers will ignore the primary MX all together and push out SPAM directly to the backup MX. Peter
On Tue, Jun 9, 2020 at 12:10 AM Peter <peter at pajamian.dhs.org> wrote:> On 9/06/20 2:56 pm, Jon LaBadie wrote: > > Don't use a backup MX, they are a relic of the 90s when mail servers > were often times not always online. a sending mail server will > generally retry the message for up to five days if your MTA is downOr have your backup MX be the same as your primary and well behaved senders will try backup MX right away leading to little delay due to graylisting.