Greylisting & Backup MX
259 views
Skip to first unread message
Bill Pye
Oct 14, 2016, 5:52:53 AM10/14/16
to rspamd
Hi
I have a backup MX provided by my DNS hosting service and when a an email is greylisted it ends up at my backup MX server for later delivery. It works and gets correctly delivered later but I'm guessing that this is not really the intent of greylisting.
Is this intended behaviour (I'm assuming it is) and should I really be using greylisting or with a backup MX does it need to be disabled or is there a way to 'correctly' use greylisting with a backup mx server?
Regards
Bill
I have a backup MX provided by my DNS hosting service and when a an email is greylisted it ends up at my backup MX server for later delivery. It works and gets correctly delivered later but I'm guessing that this is not really the intent of greylisting.
Is this intended behaviour (I'm assuming it is) and should I really be using greylisting or with a backup MX does it need to be disabled or is there a way to 'correctly' use greylisting with a backup mx server?
Regards
Bill
Andrew Lewis
Oct 14, 2016, 5:59:28 AM10/14/16
to rsp...@googlegroups.com
Hi Bill,
If your primary MX is sending temporary errors (as is the case with
greylisting) it's expected that senders will try secondary MXs.
You could configure your secondaries such that they perform
greylisting similarly to your primary.
Best,
-AL.
> --
> You received this message because you are subscribed to the Google
> Groups "rspamd" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to rspamd+un...@googlegroups.com.
> Visit this group at https://groups.google.com/group/rspamd.
If your primary MX is sending temporary errors (as is the case with
greylisting) it's expected that senders will try secondary MXs.
You could configure your secondaries such that they perform
greylisting similarly to your primary.
Best,
-AL.
> You received this message because you are subscribed to the Google
> Groups "rspamd" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to rspamd+un...@googlegroups.com.
> Visit this group at https://groups.google.com/group/rspamd.
Bill Pye
Oct 14, 2016, 6:58:44 AM10/14/16
to rspamd
Hi Andrew
Thanks for your reply. Unfortunately I don't have any control over the backup MX as it's a service provided by my DNS hosting service hence the reason I'm leaning towards greylisting being of no use in these circumstances. This is only my home mail server so there's no great amount of traffic and I've never really found the need to use greylisting. As a new user of rspamd I'm just trying to work my way through the features and as this is active from install I just thought I'd leave it and see how it went, TBH I tend to forget about the backup MX unless my server goes down which is rarely. :)
I'm also running a Zimbra Collaboration Server and I was disappointed when the DSPAM project was abandoned and then removed from ZCS, I've only recently found rspamd and think it's a great replacement but takes a bit of 'hacking' to get it into ZCS. With a reduction of 50% in cpu usage after disabling spamassassin I might even try and get this permanently incorporated into ZCS after a bit more testing.
Regards
Bill
Thanks for your reply. Unfortunately I don't have any control over the backup MX as it's a service provided by my DNS hosting service hence the reason I'm leaning towards greylisting being of no use in these circumstances. This is only my home mail server so there's no great amount of traffic and I've never really found the need to use greylisting. As a new user of rspamd I'm just trying to work my way through the features and as this is active from install I just thought I'd leave it and see how it went, TBH I tend to forget about the backup MX unless my server goes down which is rarely. :)
I'm also running a Zimbra Collaboration Server and I was disappointed when the DSPAM project was abandoned and then removed from ZCS, I've only recently found rspamd and think it's a great replacement but takes a bit of 'hacking' to get it into ZCS. With a reduction of 50% in cpu usage after disabling spamassassin I might even try and get this permanently incorporated into ZCS after a bit more testing.
Regards
Bill
Felix Schwarz
Oct 14, 2016, 7:13:32 AM10/14/16
to rspamd
Am 14.10.2016 um 12:58 schrieb Bill Pye:
> Thanks for your reply. Unfortunately I don't have any control over the backup
> MX as it's a service provided by my DNS hosting service hence the reason I'm
> leaning towards greylisting being of no use in these circumstances.
From my experience the Backup MX should perform exactly the same anti-spam
> Thanks for your reply. Unfortunately I don't have any control over the backup
> MX as it's a service provided by my DNS hosting service hence the reason I'm
> leaning towards greylisting being of no use in these circumstances.
checks as the main mailserver. In the past a lot of backup servers accepted
way more messages which lead to backscatter and spammers going directly to the
backup MX even if the main server is reachable.
Also personally I don't see any reason to use a backup MX with contemporary
technology: With things like ansible/puppet/... and virtualization it should
be possible to accept messages again within a few hours (and besides a few
servers even the biggest provides will retry for more than a day in case the
server is not up).
IMHO the most important thing with regards to mail service restore is the
ability to quickly point the domain MX records to a new IP address - in case
you need to switch to a new DC or just a new machine and you can not transfer
the IP address within a reasonable time.
fs
Bill Pye
Oct 14, 2016, 7:41:39 AM10/14/16
to rspamd
Hi Felix
Thanks for your comments. I'm not saying that the backup mx has no anti-spam systems installed (I believe it does) it's just that I don't have any control over that server. It's provided as an added service to my DNS hosting and it's a short term solution to any interruption toandy mail server being offline, it works well and the company that provides the service is a large reputable organisation that knows what it's doing with this service. I know the problems with a backup MX but I'm really just finding my way around rspamd at the moment and seeing how effective/useful each feature is in my environment. Back to my original question, does greylisting serve any useful purpose in this situation - I'm leaning towards disabling it.
Regards
Bill
Thanks for your comments. I'm not saying that the backup mx has no anti-spam systems installed (I believe it does) it's just that I don't have any control over that server. It's provided as an added service to my DNS hosting and it's a short term solution to any interruption toandy mail server being offline, it works well and the company that provides the service is a large reputable organisation that knows what it's doing with this service. I know the problems with a backup MX but I'm really just finding my way around rspamd at the moment and seeing how effective/useful each feature is in my environment. Back to my original question, does greylisting serve any useful purpose in this situation - I'm leaning towards disabling it.
Regards
Bill
Andrew Lewis
Oct 14, 2016, 7:55:51 AM10/14/16
to rsp...@googlegroups.com
Hi Bill,
> Back to my original question, does
> greylisting serve any useful purpose in this situation - I'm leaning
> towards disabling it.
It doesn't seem useful- I'd recommend disabling it.
Best,
-AL.
> Back to my original question, does
> greylisting serve any useful purpose in this situation - I'm leaning
> towards disabling it.
Best,
-AL.
Felix Schwarz
Oct 14, 2016, 8:10:20 AM10/14/16
to rspamd
Hey Bill,
Am 14.10.2016 um 13:41 schrieb Bill Pye:
> Thanks for your comments. I'm not saying that the backup mx has no anti-spam
> systems installed (I believe it does) it's just that I don't have any control
> over that server.
In my experience *any* mismatch in configuration between backup mx + "main"
mailserver will come back to haunt you. In the best case you will get more
spam which was accepted by your backup MX.
> it's a short term solution to any interruption toandy mail server being offline,
IMHO: Don't worry about loosing messages just because your server is offline
for some hours (assuming you can tolerate not being able to receive mail for a
few hours).
(YMMV - special servers/requirements/... ).
> I know the problems
> with a backup MX but I'm really just finding my way around rspamd at the
> moment and seeing how effective/useful each feature is in my environment. Back
> to my original question, does greylisting serve any useful purpose in this
> situation - I'm leaning towards disabling it.
As long as your backup MX behaves differently than your main mail server there
is no use in rejecting/deferring anything at SMTP time.
Personally I don't use greylisting because rspamd is effective enough for me.
If I feel that spam recognition rates will drop too much, I will enable it as
rspamd has grown some support for it (AFAIU even for mail clusters due to
reddis). I assume the main advantage is to wait if host sending a "suspicious"
message ends up on a few DNS blacklists which should happen pretty quickly for
typical spam senders.
Felix
Am 14.10.2016 um 13:41 schrieb Bill Pye:
> Thanks for your comments. I'm not saying that the backup mx has no anti-spam
> systems installed (I believe it does) it's just that I don't have any control
> over that server.
mailserver will come back to haunt you. In the best case you will get more
spam which was accepted by your backup MX.
> it's a short term solution to any interruption toandy mail server being offline,
for some hours (assuming you can tolerate not being able to receive mail for a
few hours).
(YMMV - special servers/requirements/... ).
> I know the problems
> with a backup MX but I'm really just finding my way around rspamd at the
> moment and seeing how effective/useful each feature is in my environment. Back
> to my original question, does greylisting serve any useful purpose in this
> situation - I'm leaning towards disabling it.
is no use in rejecting/deferring anything at SMTP time.
Personally I don't use greylisting because rspamd is effective enough for me.
If I feel that spam recognition rates will drop too much, I will enable it as
rspamd has grown some support for it (AFAIU even for mail clusters due to
reddis). I assume the main advantage is to wait if host sending a "suspicious"
message ends up on a few DNS blacklists which should happen pretty quickly for
typical spam senders.
Felix
Bill Pye
Oct 15, 2016, 7:57:50 AM10/15/16
to rspamd
Hi Felix
Thanks for your feedback, I've disabled greylisting for now but most likely for good.
Have a good week-end. :)
Regards
Bill
Thanks for your feedback, I've disabled greylisting for now but most likely for good.
Have a good week-end. :)
Regards
Bill
Marc Stürmer
Oct 27, 2016, 5:05:45 PM10/27/16
to rspamd
Am Freitag, 14. Oktober 2016 13:13:32 UTC+2 schrieb Felix Schwarz:
Also personally I don't see any reason to use a backup MX with contemporary
technology: With things like ansible/puppet/... and virtualization it should
be possible to accept messages again within a few hours (and besides a few
servers even the biggest provides will retry for more than a day in case the
server is not up).
Even without virtualization technology there is normally no reason to have a backup MX and here's why: every sane MTA will try for several days to deliver the mails in its queue, normally for up to five days. This means even if you got no backup MX and have an outage for some hours up to an day or more there will be no outage on email, all mail will be delivered if your server is back online by the originating systems itself.
So setting up a backup mx serves little purpose there.
Reply all
Reply to author
Forward
0 new messages