Greylisting: security vs. spam mitigation

Use this forum if you have installed hMailServer and want to ask a question related to a production release of hMailServer. Before posting, please read the troubleshooting guide. A large part of all reported issues are already described in detail here.
Post Reply
User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Greylisting: security vs. spam mitigation

Post by Snorkasaurus » 2014-08-04 20:41

I wanted to start a new thread since it appears as though we have inadvertently hijacked a previous question in Tips N Tricks about stopping spammers with a particular HELO string. In this other thread, jimimaseye was asking about greylisting.
jimimaseye wrote:Q: So greylisting only applies AFTER authentication has been passed? Or not?

I ask because I have authentication required on ALL connections as I dont currently use or want direct incoming mail (all mail should be going to my web host). By doing this I stop spam coming in to me by bots that have 'sniffed' an open port 25 or associated my smtp server with my domain (they may have a record of my old MX record before I deleted it). So in this scenario, from what you say, it would only greylist AFTER successful authentication?
Ahh, I think you are perhaps more interested in Auto-Ban than Greylisting. Typically when mail is being delivered from some external mail server to your mail server you'll see a conversation something like this:

Code: Select all

"SMTPD"	944	3120	"2014-08-04 00:21:59.640"	"113.173.203.60"	"SENT: 220 mail.snork.ca ESMTP NO UCE WASSUP"
"SMTPD"	944	3120	"2014-08-04 00:22:00.125"	"113.173.203.60"	"RECEIVED: EHLO [113.173.203.60]"
"SMTPD"	944	3120	"2014-08-04 00:22:00.125"	"113.173.203.60"	"SENT: 250-69-165-220-221.dsl.teksavvy.com[nl]250-SIZE 20480000[nl]250 AUTH LOGIN"
"SMTPD"	944	3120	"2014-08-04 00:22:00.531"	"113.173.203.60"	"RECEIVED: MAIL From:<ycayuvi5274@2mpd.org>"
"SMTPD"	944	3120	"2014-08-04 00:22:00.531"	"113.173.203.60"	"SENT: 250 OK"
"SMTPD"	944	3120	"2014-08-04 00:22:00.984"	"113.173.203.60"	"RECEIVED: RCPT To:<someguy@snork.ca>"
"SMTPD"	944	3120	"2014-08-04 00:22:01.000"	"113.173.203.60"	"SENT: 451 Please try again later."
As you can see, as soon as hMailServer has (1) the IP address of the remote system (2) who the message is FROM and (3) who it is TO - it can create a "triplet" with that information and tell the remote system to come back later. However, when you have a client PC (one of your legitimate users) connecting to your mail server to deliver mail, the conversation is likely different... such as:

Code: Select all

"SMTPD"	944	3363	"2014-08-04 08:40:56.812"	"192.168.1.200"	"SENT: 220 mail.snork.ca ESMTP NO UCE WASSUP"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"RECEIVED: EHLO www.snork.ca"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"SENT: 250-69-165-220-221.dsl.teksavvy.com[nl]250-SIZE 20480000[nl]250 AUTH LOGIN"
"SMTPD"	944	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"RECEIVED: AUTH LOGIN"
"SMTPD"	944	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"SENT: 334 XXXXXXXXXXXX"
"SMTPD"	944	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"RECEIVED: EEEEEEEEEEEEEEEEEEE="
"SMTPD"	944	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"SENT: 334 UUUUUUUUUUUU"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.828"	"192.168.1.200"	"RECEIVED: ***"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"SENT: 235 authenticated."
"SMTPD"	2924	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"RECEIVED: MAIL FROM:<someguy@snork.ca>"
"SMTPD"	2924	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"SENT: 250 OK"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"RECEIVED: RCPT TO:<some_address@hotmail.com>"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"SENT: 250 OK"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"RECEIVED: DATA"
"SMTPD"	1600	3363	"2014-08-04 08:40:56.843"	"192.168.1.200"	"SENT: 354 OK, send."
"SMTPD"	2736	3363	"2014-08-04 08:40:56.906"	"192.168.1.200"	"SENT: 250 Queued (0.015 seconds)"
You'll notice that the AUTH LOGIN command on the fourth line (which in this case came from my RoundCube web server) is before the MAIL FROM and RCPT TO commands. Now, if spammers are trying to hack your account(s) they will have an authentication failure and will restart the authentication process, rather than proceed to the step of saying who the message is from. If they fail this process too many times (based on your settings) they get:

Code: Select all

"SMTPD"	3936	1939	"2014-07-22 17:41:41.822"	"78.111.3.71"	"SENT: 220 mx1.snork.ca ESMTP"
"SMTPD"	3936	1939	"2014-07-22 17:41:42.057"	"78.111.3.71"	"RECEIVED: EHLO OMSGS01Test"
"SMTPD"	3936	1939	"2014-07-22 17:41:42.057"	"78.111.3.71"	"SENT: 250-mx1.snork.ca[nl]250-SIZE 20480000[nl]250 AUTH LOGIN"
"SMTPD"	3936	1939	"2014-07-22 17:41:42.307"	"78.111.3.71"	"RECEIVED: AUTH login AAAAAAAAAAA="
"SMTPD"	3936	1939	"2014-07-22 17:41:42.307"	"78.111.3.71"	"SENT: 334 GGGGGGGGGGGG"
"SMTPD"	3936	1939	"2014-07-22 17:41:42.541"	"78.111.3.71"	"RECEIVED: ***"
"SMTPD"	3936	1939	"2014-07-22 17:41:42.572"	"78.111.3.71"	"SENT: 535 Authentication failed. Too many invalid logon attempts."
So to answer your actual question, yes... greylisting is applied after the authentication process. Is your problem that you see too many incidents like this last log? If so, you can tighten up on your Auto-Ban settings but the lower you set the threshold the more users will lock themselves out (unless they all store their password in their mail client). You're best bet might be to just monitor the attempts to see if anyone is actually trying to hack a real account (instead of just made up user account names). Does that make a little more sense?

Snork.

User avatar
SorenR
Senior user
Senior user
Posts: 3183
Joined: 2006-08-21 15:38
Location: Denmark

Re: Greylisting: security vs. spam mitigation

Post by SorenR » 2014-08-04 21:32

Snorkasaurus wrote:So to answer your actual question, yes... greylisting is applied after the authentication process.
There is NO authentication involved in GreyListing.

GreyListing is a tool used to fight SPAM sent from one mailserver to another mailserver...

For the "novice" this is how I usually explain GreyListing.. :wink:

Scenario 1 - regular mail (no SPF check):
==> ServerA to ServerB; I have an email from UserA to UserB.
==> ServerB to ServerA; OK, but can you wait a bit and send it again?
==> ServerA to ServerB; OK, bye...
==> ServerB take note: ServerA, UserA, UserB
.. a bit later ...
==> ServerA to ServerB; I have an email from UserA to UserB.
==> ServerB to ServerA; Let me check my notes... OK, go ahead...
==> ServerA to ServerB; Done
==> ServerB to ServerA; OK Thanks...

Scenario 2 - SPAM mass mailer (no SPF check):
==> ServerA to ServerB; I have an email from UserA to UserB.
==> ServerB to ServerA; OK, but can you wait a bit and send it again?
==> ServerA to ServerB; OK (no way - time is money - NEXT!)
==> ServerB take note: ServerA, UserA, UserB
.. a while later ...
==> ServerB; whatever happened to ServerA? No need to hang on to note...
SørenR.

“With age comes wisdom, but sometimes age comes alone.”
- Oscar Wilde

User avatar
jimimaseye
Moderator
Moderator
Posts: 8118
Joined: 2011-09-08 17:48

Re: Greylisting: security vs. spam mitigation

Post by jimimaseye » 2014-08-04 22:38

Here is an extract from my log file:

Code: Select all


"SMTPD"	2144	1297	"2014-07-10 01:30:34.224"	"190.189.92.132"	"SENT: 220 Northcote SMTP"
"SMTPD"	2272	1297	"2014-07-10 01:30:34.505"	"190.189.92.132"	"RECEIVED: EHLO bopubgcwoy"
"SMTPD"	2272	1297	"2014-07-10 01:30:34.505"	"190.189.92.132"	"SENT: 250-decroSMTP.mydomain.co.uk[nl]250-SIZE 25600000[nl]250 AUTH LOGIN"
"SMTPD"	2180	1297	"2014-07-10 01:30:34.786"	"190.189.92.132"	"RECEIVED: AUTH LOGIN"
"SMTPD"	2180	1297	"2014-07-10 01:30:34.786"	"190.189.92.132"	"SENT: 334 DFYUIOPkuh"
"SMTPD"	2100	1297	"2014-07-10 01:30:35.067"	"190.189.92.132"	"RECEIVED: sdfghjdfghjcfghjcghjchj"
"SMTPD"	2100	1297	"2014-07-10 01:30:35.067"	"190.189.92.132"	"SENT: 334 Urtyuioghj"
"SMTPD"	2248	1297	"2014-07-10 01:30:35.332"	"190.189.92.132"	"RECEIVED: ***"
"SMTPD"	2248	1297	"2014-07-10 01:30:35.363"	"190.189.92.132"	"SENT: 535 Authentication failed. Restarting authentication process."
----------------
"SMTPD"	2088	1297	"2014-07-10 01:30:35.659"	"190.189.92.132"	"RECEIVED: QUIT"
"SMTPD"	2088	1297	"2014-07-10 01:30:35.659"	"190.189.92.132"	"SENT: 221 goodbye"
This is someone trying to get in to my machine. Now compare it to

Code: Select all

"SMTPD"	2144	3167	"2014-07-10 09:27:46.395"	"192.168.0.3"	"SENT: 220 Northcote SMTP"
"SMTPD"	2104	3167	"2014-07-10 09:27:46.395"	"192.168.0.3"	"RECEIVED: EHLO [192.168.0.3]"
"SMTPD"	2104	3167	"2014-07-10 09:27:46.395"	"192.168.0.3"	"SENT: 250-decroSMTP.mydomain.co.uk[nl]250-SIZE 25600000[nl]250 AUTH LOGIN"
"SMTPD"	2248	3167	"2014-07-10 09:27:46.426"	"192.168.0.3"	"RECEIVED: AUTH LOGIN"
"SMTPD"	2248	3167	"2014-07-10 09:27:46.426"	"192.168.0.3"	"SENT: 334 DFYUIOPkuh"
"SMTPD"	2140	3167	"2014-07-10 09:27:46.442"	"192.168.0.3"	"RECEIVED: sdfghjdfghjcfghjcghjchj"
"SMTPD"	2140	3167	"2014-07-10 09:27:46.442"	"192.168.0.3"	"SENT: 334 Urtyuioghj"
"SMTPD"	2144	3167	"2014-07-10 09:27:46.442"	"192.168.0.3"	"RECEIVED: ***"
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"SENT: 235 authenticated."
-----------------
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"RECEIVED: MAIL FROM:<user1@mydomain.co.uk> SIZE=33797"
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"SENT: 250 OK"
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"RECEIVED: RCPT TO:<outsiderecipient@theworld.com>"
    <----------->
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"SENT: 250 OK"
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"RECEIVED: DATA"
"SMTPD"	2144	3167	"2014-07-10 09:27:46.457"	"192.168.0.3"	"SENT: 354 OK, send."
"SMTPD"	2436	3167	"2014-07-10 09:27:46.535"	"192.168.0.3"	"SENT: 250 Queued (0.016 seconds)"
"SMTPD"	2116	3167	"2014-07-10 09:27:46.535"	"192.168.0.3"	"RECEIVED: QUIT"
( the dashes provided to show similarities in steps)

Now look at the log where a direct inbound SMTP mail is received WITHOUT AUTHENTICATION (ie, my box was open to inbound deliveries)

Code: Select all

"SMTPD"	2824	3722	"2013-12-12 11:53:55.252"	"213.123.20.128"	"SENT: 220 Northcote SMTP"
"SMTPD"	3488	3722	"2013-12-12 11:53:55.267"	"213.123.20.128"	"RECEIVED: EHLO mail.btconnect.com"
"SMTPD"	3488	3722	"2013-12-12 11:53:55.267"	"213.123.20.128"	"SENT: 250-decroSMTP.mydomain.co.uk[nl]250-SIZE 20480000[nl]250 AUTH LOGIN"
---------------
"SMTPD"	1856	3722	"2013-12-12 11:53:55.283"	"213.123.20.128"	"RECEIVED: MAIL From:<bill@theoutsideworld.co.uk> SIZE=28931"
"SMTPD"	1856	3722	"2013-12-12 11:53:55.969"	"213.123.20.128"	"SENT: 250 OK"
"SMTPD"	3820	3722	"2013-12-12 11:53:56.000"	"213.123.20.128"	"RECEIVED: RCPT To:<user1@mydomain.co.uk>"
    <----------->
"SMTPD"	3820	3722	"2013-12-12 11:53:56.000"	"213.123.20.128"	"SENT: 250 OK"
"SMTPD"	1896	3722	"2013-12-12 11:53:56.016"	"213.123.20.128"	"RECEIVED: DATA"
"SMTPD"	1896	3722	"2013-12-12 11:53:56.016"	"213.123.20.128"	"SENT: 354 OK, send."
"SMTPD"	3560	3722	"2013-12-12 11:54:11.288"	"213.123.20.128"	"SENT: 250 Queued (15.179 seconds)"
"APPLICATION"	1272	"2013-12-12 11:54:11.320"	"SMTPDeliverer - Message 178851: Delivering message from bill@theoutsideworld.co.uk to user1@mydomain.co.uk. File: D:\Datastore\hMailData\{EF17BC5C-1C75-4D3A-95BF-31141E25E03D}.eml"
"SMTPD"	3740	3722	"2013-12-12 11:54:13.784"	"213.123.20.128"	"RECEIVED: QUIT"
In all the scenarios, at what point would the greylisting cutoff of "SENT: 451 Please try again later." be issued and where would it appear (if at all)? Because from Snorks example it appears at the end straight after the 'RCPT TO' (position marked as <-----------> above).

(Youll note that the first and second logs asks for AUTH regardless, as does the second. Because Ive told the system to do so for every delivery (ext to local, local to ext, ext to ext (obviously) and even local to local). So the AUTH command is requested before any other recipient question.)

That tells me that if the external spammer attempts access to my machine, and tells me that he is wanting to send email <fromexternal> to RCPT <external> he would be asked for AUTH LOGIN (as that is the security set in my HMS). But would he? Or, as above, after receiving the RCPT TO: <external_account> would he simply be grey listed? (becaise it is at this same time that HMS decides to grey list and to ask for authentication. So what comes first?)
HMS 5.6.6 B2383 on Win Server 2008 R2 Foundation, + 5.6.7-B2415 on test.
SpamassassinForWindows 3.4.0 spamd service
AV: Clamwin + Clamd service + sanesecurity defs : https://www.hmailserver.com/forum/viewtopic.php?f=21&t=26829

User avatar
SorenR
Senior user
Senior user
Posts: 3183
Joined: 2006-08-21 15:38
Location: Denmark

Re: Greylisting: security vs. spam mitigation

Post by SorenR » 2014-08-04 22:49

It won't...

GreyListing ONLY works on incoming mail via SMTP from non-authenticated source.

If I send an email - authenticate on YOUR server from my client - there is NO GreyListing.

If I send en email from MY gmail.com account to YOUR email on YOUR server, YOUR server will GreyList Gmail and it will take forever for my email to reach you.
SørenR.

“With age comes wisdom, but sometimes age comes alone.”
- Oscar Wilde

User avatar
jimimaseye
Moderator
Moderator
Posts: 8118
Joined: 2011-09-08 17:48

Re: Greylisting: security vs. spam mitigation

Post by jimimaseye » 2014-08-04 23:11

SorenR wrote:It won't...

GreyListing ONLY works on incoming mail via SMTP from non-authenticated source.
Riiiiiight. THAT'S the bit that was missing.

Ok, cheers Soren.
HMS 5.6.6 B2383 on Win Server 2008 R2 Foundation, + 5.6.7-B2415 on test.
SpamassassinForWindows 3.4.0 spamd service
AV: Clamwin + Clamd service + sanesecurity defs : https://www.hmailserver.com/forum/viewtopic.php?f=21&t=26829

User avatar
SorenR
Senior user
Senior user
Posts: 3183
Joined: 2006-08-21 15:38
Location: Denmark

Re: Greylisting: security vs. spam mitigation

Post by SorenR » 2014-08-04 23:23

If you have a problem with bots trying to login (AUTH LOGIN), have a look here...
http://www.hmailserver.com/forum/viewto ... 35#p161235

I have been scripting on OnClientConnect for a month or so and I have yet to see bots try to login to SMTP port 587... I use 587 as client connect port - no SSL at present..
SørenR.

“With age comes wisdom, but sometimes age comes alone.”
- Oscar Wilde

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Greylisting: security vs. spam mitigation

Post by Snorkasaurus » 2014-08-04 23:39

Hey Jim,

If you enable greylisting, your system would send "SENT: 451 Please try again later" immediately after the remote system sends you "RCPT TO: your_account@yourdomain.com".

So in your first scenario greylisting would not happen at all because the conversation never gets that far. In the second scenario greylisting does not happen because the user has been successfully authenticated to a local account. In the third scenario it is my understanding that greylisting would happen immediately after

Code: Select all

"RECEIVED: RCPT To:<user1@mydomain.co.uk>"
jimimaseye wrote:Youll note that the first and second logs asks for AUTH regardless, as does the second
It is my understanding that when your system sends

Code: Select all

"SENT: 250-decroSMTP.mydomain.co.uk[nl]250-SIZE 20480000[nl]250 AUTH LOGIN"
It is not necessarily requesting a login but rather is just indicating that "AUTH LOGIN" is an available command. You'll notice in my logs above that even when my web server connects, it is also presented with an AUTH LOGIN. If you telnet to your mail server on port 25 you will see that you can issue a "MAIL FROM" command without having to first authenticate.

So the part that can suck is [as SorenR points out] when someone sends you mail from GMail it first arrives from 11.22.33.44 and your greylisting says "come back later". Five minutes later Google tries to resend the same message from 22.22.22.22 and is re-greylisted. Then five minutes later it ... well, you can see that the message takes forever and doesn't get delivered until it happens to be coming from a previously-tried IP address. If you want to enable greylisting but are worried about delays from email providers who frequently bounce mail around internally I can provide my list of greylist-whitelisted IP's which includes Google, Microsoft, Yahoo!, and Amazon.

However, if you are setup to require authentication for ALL external/internal mail delivery (and it sounds like you are) then it you don't really need greylisting.

My 3¢
S.

User avatar
mattg
Moderator
Moderator
Posts: 20108
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Greylisting: security vs. spam mitigation

Post by mattg » 2014-08-04 23:58

Snorkasaurus wrote:However, if you are setup to require authentication for ALL external/internal mail delivery (and it sounds like you are) then it you don't really need greylisting.
If you are set for all mail that is external to local to require authentication then you will NEVER get any external mail.

If you require authentication for all local to ANY mail, then you can still enable greylisting for ALL external to local mail, and this will very significantly impact on the amount of SPAM you receive
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

User avatar
jimimaseye
Moderator
Moderator
Posts: 8118
Joined: 2011-09-08 17:48

Re: Greylisting: security vs. spam mitigation

Post by jimimaseye » 2014-08-05 00:07

Cheers guys.

The reality is that I no longer accept incoming messages any more, for reasons I have explained on other threads (see reasons here: http://www.hmailserver.com/forum/viewto ... 9&e=164269). I used to, though, and consequently these issues may have been relevant then and perhaps in the future may be again. I talk about these issues for my curiosity (knowledge is power an all that) and mainly to complete threads with comprehensive information for others who might find it useful. (f it werent for forums and threads by people asking similar questions that I needed the answers for I would never have got hmailserver going in the first place.) I find I do ask a lot of questions so hopefully all answers get covered and ultimately enough information is there for one to conclude they understand....including myself.

Just doing my duty. :-)

"Take care of yourself...and each other". Time for another beer!

Jerry *hic*

(p.s is it coincidence I am suffering mild insomnia and not tired at night whilst my missus and toddler son are away....or expected?!)
HMS 5.6.6 B2383 on Win Server 2008 R2 Foundation, + 5.6.7-B2415 on test.
SpamassassinForWindows 3.4.0 spamd service
AV: Clamwin + Clamd service + sanesecurity defs : https://www.hmailserver.com/forum/viewtopic.php?f=21&t=26829

User avatar
mattg
Moderator
Moderator
Posts: 20108
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Greylisting: security vs. spam mitigation

Post by mattg » 2014-08-05 00:13

from here >> http://www.hmailserver.com/forum/viewto ... 85&start=0
Snorkasaurus wrote:If I may elaborate a bit...

The reason I do not have "bypass on SPF" enabled is because I had a wave of spam [more than a year ago now] that was coming from SPF'ed domains. The spammers basically found some domains that had a +all in their SPF records, allowing delivery from anywhere.
+1
The whole SPF thing doesn't wok while some admins put +all at the end of their spf records, unless we can stop accepting them

In some of Bill's recent ALPHA builds, he has set an INI setting that allows for a default SPF record, and can choose to ignore +all SPF records. Unsure if that extends to the bypass greylisting part of hmailserver or not, but certainly does affect SPAM score generally.

I hope that Martin/Bill will include this SPF work in the main builds
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

User avatar
mattg
Moderator
Moderator
Posts: 20108
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Greylisting: security vs. spam mitigation

Post by mattg » 2014-08-05 00:16

jimimaseye wrote:(p.s is it coincidence I am suffering mild insomnia and not tired at night whilst my missus and toddler son are away....or expected?!)
One of the doctors I know says that Monitors, TVs and iPads emit light at a specific frequency that keeps you awake.
Perhaps, because your family is away, you are surfing the net more...

Perhaps too, you just miss them. :wink:

Matt
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

User avatar
jimimaseye
Moderator
Moderator
Posts: 8118
Joined: 2011-09-08 17:48

Re: Greylisting: security vs. spam mitigation

Post by jimimaseye » 2014-08-05 00:23

Yes, (the light thing) its true. (Its about the 'blue' light. You can actually buy lights the emit the similar colour to replicate daylight and wake you up instead of an actual alarm clock.)

Not sure about 'missing them' more being the cause, more that they have not been here physically and mentally wearing me down all day!
HMS 5.6.6 B2383 on Win Server 2008 R2 Foundation, + 5.6.7-B2415 on test.
SpamassassinForWindows 3.4.0 spamd service
AV: Clamwin + Clamd service + sanesecurity defs : https://www.hmailserver.com/forum/viewtopic.php?f=21&t=26829

User avatar
mattg
Moderator
Moderator
Posts: 20108
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Greylisting: security vs. spam mitigation

Post by mattg » 2014-08-05 00:55

jimimaseye wrote:...more that they have not been here physically and mentally wearing me down all day!
yep :lol:
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: Greylisting: security vs. spam mitigation

Post by ^DooM^ » 2014-08-05 01:26

Greylisting is great until you have a big email network that places your email in a big database that any one of thousands of servers will attempt to send all from different IP's at which point it will forever get delayed by your mail server.

As with any spam fighting technology, it is always advisable to keep an eye on it and tweak (Whitelist in this case) to keep your server working efficiently.
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

Post Reply