|
From: Ray B. <rj_...@rj...> - 2005-06-16 07:31:15
|
Hi I have started to notice more and more spam emails that are being sent by MTAs that use the next available MX after I greylist the initial connect. My server then in turn greylists the connect from the backup MX but it doesn't stop the spam or virus being delivered in the end. Are we seeing an increase in the number of spam sending MTAs that don't give up on the first attempt? I don't like to think that this is so because SQLGrey does work incredibly well with the current connections we receive. Any thoughts on this issue? Regards Ray |
|
From: Michel B. <mi...@bo...> - 2005-06-16 07:41:53
|
Le Jeudi 16 Juin 2005 09:31, Ray Booysen a =E9crit : > > I have started to notice more and more spam emails that are being sent > by MTAs that use the next available MX after I greylist the initial > connect. I see the same. > My server then in turn greylists the connect from the backup=20 > MX but it doesn't stop the spam or virus being delivered in the end. This is *NOT* good ! If the primary MX performs greylisting, then *ALL* the backup MXes MUST=20 perform greylisting themselves as well. As a rule of thumb, *ANY* anti-spam measure that exists on a primary MX a= t=20 SMTP level MUST exist as well on all secondaries. Otherwise secondaries a= re=20 easy ways to bypass antispam protection for a given domain, and spammers = know=20 that well (some spammers / spambots systematically send to the LOWEST=20 priority MX to exploit this possible, and alas frequent, security=20 shortcoming). And the primary MX should not greylist mail coming from its secondaries (= they=20 should be whitelisted), as greyliting secondaries is not only useless but= =20 also counterproductive. > Are we seeing an increase in the number of spam sending MTAs that don't > give up on the first attempt? I believe so. And I also have seen a growing number of spams that retry a= fter=20 about a minute. But not longer. Which means that greylisting duration sho= uld=20 probably not being set < 2 minutes. Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Ray B. <rj_...@rj...> - 2005-06-16 07:59:07
|
Michel Bouissou wrote: >Le Jeudi 16 Juin 2005 09:31, Ray Booysen a =E9crit : > =20 > >>I have started to notice more and more spam emails that are being sent >>by MTAs that use the next available MX after I greylist the initial >>connect. >> =20 >> > >I see the same. > > =20 > >>My server then in turn greylists the connect from the backup=20 >>MX but it doesn't stop the spam or virus being delivered in the end. >> =20 >> > >This is *NOT* good ! > >If the primary MX performs greylisting, then *ALL* the backup MXes MUST=20 >perform greylisting themselves as well. > > =20 > Unfortunately I don't have control over any secondaries. Anyone know of=20 a host that will sell me secondary services and implement greylisting? :) >As a rule of thumb, *ANY* anti-spam measure that exists on a primary MX = at=20 >SMTP level MUST exist as well on all secondaries. Otherwise secondaries = are=20 >easy ways to bypass antispam protection for a given domain, and spammers= know=20 >that well (some spammers / spambots systematically send to the LOWEST=20 >priority MX to exploit this possible, and alas frequent, security=20 >shortcoming). > >And the primary MX should not greylist mail coming from its secondaries = (they=20 >should be whitelisted), as greyliting secondaries is not only useless bu= t=20 >also counterproductive. > =20 > I know this. I just havn't whitelisted the IP yet. Will get onto that > =20 > >>Are we seeing an increase in the number of spam sending MTAs that don't >>give up on the first attempt? >> =20 >> > >I believe so. And I also have seen a growing number of spams that retry = after=20 >about a minute. But not longer. Which means that greylisting duration sh= ould=20 >probably not being set < 2 minutes. > =20 > Thanks for the tip! :) >Cheers. > > =20 > Thanks for thelp help Michael! Regards Ray |
|
From: Michel B. <mi...@bo...> - 2005-06-16 08:13:08
|
Le Jeudi 16 Juin 2005 09:58, Ray Booysen a =E9crit : > > >If the primary MX performs greylisting, then *ALL* the backup MXes MUS= T > >perform greylisting themselves as well. > > Unfortunately I don't have control over any secondaries. Then don't use secondaries. Secondaries MUST be under the same administra= tive=20 control than the primary. Otherwise it's better not to use secondaries (a= s=20 secondary MXes are not necessary anyway, and will cause more trouble than= =20 they will help, if they become an easy gateway for spam and viruses). --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-06-16 08:23:34
|
Ray Booysen wrote the following on 16.06.2005 09:58 : > Unfortunately I don't have control over any secondaries. Anyone know > of a host that will sell me secondary services and implement > greylisting? :) The fact is: you probably don't need a secondary MX (in fact no sane configuration should). SMTP guarantees that the sending host will retry a failed transaction latter without the message originator even noticing this (unless the message is delayed for long and the MTA is configured to warn when a message is delayed for more than a specified amount of time).So if your primary goes down, either you put it back before the messages expire in their queues and your users get them or you aren't quick enough and whatever the case the messages will be bounced back from the queue they are sitting in (either the origin MTA or the secondary MX). Simply remove the secondary MX from the DNS config and when the TTL expires remove it from your trusted sources in your local Postfix configuration. Lionel. |
|
From: Ray B. <rj_...@rj...> - 2005-06-16 08:42:15
|
Lionel Bouton wrote: >The fact is: you probably don't need a secondary MX (in fact no sane >configuration should). > > Hey Why do you and Michael think that backup MX servers aren't neccesary? Bouissou.net has 3 MX servers listed. I don't understand why they are unneccesary. Regards Ray |
|
From: Lionel B. <lio...@bo...> - 2005-06-16 09:08:31
|
Ray Booysen wrote the following on 16.06.2005 10:42 :
> Lionel Bouton wrote:
>
>> The fact is: you probably don't need a secondary MX (in fact no sane
>> configuration should).
>>
>
> Hey
>
> Why do you and Michael think that backup MX servers aren't neccesary?
As I said, until the server doing the actual delivery to the mailboxes
is up, you only shift the task of retrying a failed delivery from the
original MTA to your backup MX servers. The only benefit is when you
control the backup MX servers and can make them flush their queues as
soon as the "delivery" server is back online : the messages won't get
delayed as much as if the original MTAs would have retried themselves.
If you don't have any control over the backup MX servers, then you don't
gain anything from them, in fact as you witness yourself you only weaken
your anti-spam solutions. The name "backup" MX server is in fact
misleading, you don't backup anything with it as the so-called "backup"
MX is useless without the "delivery" server : you can't use it as your
primary server (delivering mails to users, allowing them to fetch
through POP3(s) or IMAP) if the original goes down.
Backup MX providers are mostly misguided ("everyone provide a backup MX
service, we must do it too") or knowingly trying to suck money from you
without any real service provided.
Lionel.
|
|
From: Ray B. <rj_...@rj...> - 2005-06-16 09:20:20
|
Lionel Bouton wrote:
>Backup MX providers are mostly misguided ("everyone provide a backup MX
>service, we must do it too") or knowingly trying to suck money from you
>without any real service provided.
>
>Lionel.
>
>
>
Hi Lionel
Thanks for the info!
Regards
Ray
|
|
From: Michel B. <mi...@bo...> - 2005-06-16 09:16:05
|
Le Jeudi 16 Juin 2005 10:42, Ray Booysen a =E9crit : > > Why do you and Michael think that backup MX servers aren't neccesary? =A0 > Bouissou.net has 3 MX servers listed. =A0I don't understand why they ar= e > unneccesary. All my 3 MXes (for my personal bouissou.net domain) are GNU/Linux compute= rs=20 that are connected thru residential ADSL, so they might experiment=20 reliability or connectivity problems. Although it doesn't usually happen,= it=20 could, and that's why I use backup MXes. I must stress the fact that I do have administrative control over all of = those=20 (and actually 2 MX names currently point to the same IP address, one bein= g=20 dynamic and set there for line backup purposes). Having administrative=20 control over all of my MXes allow me to guarantee that they implement the= =20 same level of filtering, and greylisting on all. The major (and only) advantages of having such backup MXes is that: 1/ In case the primary goes down, and mail gets queued on the secondary, = when=20 the primary comes back I can get waiting mail immediately (using SMTP ETR= N)=20 without having to wait for remote servers to retry at their own will with= =20 their own schedule. For this to be useful, of course, you have to be able= to=20 perform ETRN on your secondaries. 2/ I can set a queue lifetime longer than the defaults on my secondaries,= =20 which allows mail to stay waiting there "longer than normal" (usually 5 d= ays)=20 without bouncing back, in case I would experiment a very long primary=20 downtime for some reason (i.e. major hardware failure that I couldn't qui= ckly=20 fix). But in your case, if you state that you have no control over your seconda= ries,=20 you probably cannot benefice from any of these features, and then the=20 baseline is that you shouldn't use thoses MXes over which you have no=20 control. All it can bring you is trouble. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Ray B. <rj_...@rj...> - 2005-06-16 09:19:51
|
Michel Bouissou wrote: >But in your case, if you state that you have no control over your secondaries, >you probably cannot benefice from any of these features, and then the >baseline is that you shouldn't use thoses MXes over which you have no >control. All it can bring you is trouble. > > > Thanks for the tip Michel. I wasn't picking you out, just researching :) Regards Ray |
|
From: Lionel B. <lio...@bo...> - 2005-06-16 08:16:54
|
Michel Bouissou wrote the following on 16.06.2005 09:41 : >>Are we seeing an increase in the number of spam sending MTAs that don't >>give up on the first attempt? >> >> > >I believe so. And I also have seen a growing number of spams that retry after >about a minute. But not longer. Which means that greylisting duration should >probably not being set < 2 minutes. > > I've seen this too. The new default in 1.6.0 will be 5 minutes instead of 1 minute (I've only witnessed retries from real MTAs after at least 6 minutes). Lionel |
|
From: Michel B. <mi...@bo...> - 2005-06-16 08:24:19
|
Le Jeudi 16 Juin 2005 10:16, Lionel Bouton a =E9crit : > > >>Are we seeing an increase in the number of spam sending MTAs that don= 't > >>give up on the first attempt? > > > >I believe so. And I also have seen a growing number of spams that retr= y > > after about a minute. But not longer. Which means that greylisting > > duration should probably not being set < 2 minutes. > > I've seen this too. The new default in 1.6.0 will be 5 minutes instead > of 1 minute (I've only witnessed retries from real MTAs after at least = 6 > minutes). Yes. I use 5 minutes myself. I've seen that most legitimate servers have = an=20 average retry time around 19 minutes, so it doesn't hurt much increasing=20 greylisting delay a little. Of course spammers may still increase their retry delay, but the more the= y=20 will increase it, the more burden it will put on their systems, the more = it=20 will slow down their throughput, and the more chances it will give that t= heir=20 IP gets into some blacklists before they retry. So that's all benefit=20 anyway ;-) BTW Lionel, have you made your decision about whether to put throttling i= n=20 1.6.0, and which algorithm to use ? --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-06-16 08:40:20
|
Michel Bouissou wrote the following on 16.06.2005 10:24 : >BTW Lionel, have you made your decision about whether to put throttling in >1.6.0, and which algorithm to use ? > > > Throttling will be in 1.7.0, this way we'll get the time needed to experiment and iron out the details before putting it into a stable release. Lionel |