On Fri, February 13, 2015 11:52 am, Les Mikesell wrote:> On Fri, Feb 13, 2015 at 11:39 AM, Valeri Galtsev > <galtsev at kicp.uchicago.edu> wrote: >> >>> Otherwise it accept junk that your primary rejects >> >> Not exactly. If greylisting on primary is set, but on backup MX is not, >> still what is killed by greylisting by primary MX, almost never will >> come >> through backup MX. This is due to the same reason why greylisting is >> efficient: it trows off all that doesn't behave as mail server (thus >> never >> comes for re-delivery, and definitely doesn't try backup MX which real >> servers always do even before attempt of re-delivery). > > I'm not convinced. Spam is big business and trying a 2nd MX is cheap.I stated pure observation on at least two pairs of primary - backup MX I maintain. Still I made backup MXes with greylisting as well (they are separately hit by same bad spammers scripts, at a rate about 10 times smaller than primary MXes are and absolutely independently).> >> Still, it is good >> to have the same greylisting on backup MX. And all other blows and >> whistles. > > Greylisting would be kind of hard to do right. You'd have to keep the > known-good senders in sync across the receivers. But my bigger worry > would be a dictionary-type attack on user names as recipients if you > don't have access to the real user list on the secondary.With standard backup MX based on postix (with rather trivial configuration) you always do have list of legitimate recipients of primary MX on the secondary MX. Sorry if my previous e-mail is not explicit enough about it. It's a work, however, to maintain that table on backup MX (so your backup MX does accept mail for newly added users to primary MX). But having backup MX receiving everything is wrong configuration prone to backscatter - at least I see we agree on that. So, just don't roll out badly configured backup MX, I would say. Valeri> Aside from > the blowback of the bounces, if you've ever accepted an address it is > likely to get on lists of known-good spam and cause extra traffic > forever after. > > -- > Les Mikesell > lesmikesell at gmail.com > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, Feb 13, 2015 at 12:32 PM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:> > I stated pure observation on at least two pairs of primary - backup MX I > maintain. Still I made backup MXes with greylisting as well (they are > separately hit by same bad spammers scripts, at a rate about 10 times > smaller than primary MXes are and absolutely independently).I think that's unusual - spammers often target the secondaries as a preference on the premise that they are likely to not be as well-configured as the primary. But it has been a while since I ran one so maybe things have changed.>>> Still, it is good >>> to have the same greylisting on backup MX. And all other blows and >>> whistles. >> >> Greylisting would be kind of hard to do right. You'd have to keep the >> known-good senders in sync across the receivers. But my bigger worry >> would be a dictionary-type attack on user names as recipients if you >> don't have access to the real user list on the secondary. > > With standard backup MX based on postix (with rather trivial > configuration) you always do have list of legitimate recipients of primary > MX on the secondary MX.Doing greylisting right means you also have to keep the table of already-known senders up to date and that may be very dynamic. -- Les Mikesell lesmikesell at gmail.com
On Fri, February 13, 2015 12:41 pm, Les Mikesell wrote:> On Fri, Feb 13, 2015 at 12:32 PM, Valeri Galtsev > <galtsev at kicp.uchicago.edu> wrote: >> >> I stated pure observation on at least two pairs of primary - backup MX I >> maintain. Still I made backup MXes with greylisting as well (they are >> separately hit by same bad spammers scripts, at a rate about 10 times >> smaller than primary MXes are and absolutely independently). > > I think that's unusual - spammers often target the secondaries as a > preference on the premise that they are likely to not be as > well-configured as the primary. But it has been a while since I ran > one so maybe things have changed.Consider me lucky...> >>>> Still, it is good >>>> to have the same greylisting on backup MX. And all other blows and >>>> whistles. >>> >>> Greylisting would be kind of hard to do right. You'd have to keep the >>> known-good senders in sync across the receivers. But my bigger worry >>> would be a dictionary-type attack on user names as recipients if you >>> don't have access to the real user list on the secondary. >> >> With standard backup MX based on postix (with rather trivial >> configuration) you always do have list of legitimate recipients of >> primary >> MX on the secondary MX. > > Doing greylisting right means you also have to keep the table of > already-known senders up to date and that may be very dynamic. >If you are kind person, yes. Sqlgrey is designed to work simultaneously for primary, secondary (and tretary maybe - didn't check) MXes. Yet, even if they are independent, all will work, you are just not being nice to other servers and make them make 3 delivery attempts (the last is successful) instead of two (that is: primary MX - "temporary failure", secondary - "temporary failure", primary after some time - accepted; instead of primary MX - "temporary failure", secondary - accepted which will be in nice configuration common for both MXes greylisting engine and database). Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++