hMailServer forum

Posted: **2019-06-21 06:09**

I just recently Whitelisted *@fedex.com under the Anti-spam tree option in hMailAdmin.
1. I received an email from 'TrackingUpdates@fedex.com' (no quotes) which was marked as SPAM by hMailServer due to the SPAM Threshold Mark level being met.
2. Whitelisting is supposed to cause the Anti-spam processing to not be performed.
3. Checking the hMailServer Logs, I see where the Anti-spam processing took place.
a. hMailServer checked the Blacklists.
b. SPF and DKIM tests were performed and the DKIM Test failed generating a SPAM Score of 5 for the failure.
c. As per the current Help Documentation these tests were not to be performed due to '*@fedex.com' being Whitelisted.
4. I can see one possibility for hMailServer performing the SPAM Tests.
a. The Return Path in the Message Headers was 'prvs=4073a73a4e=bounce@nds.fedex.com'. hMailServer I believe examines the Message that it receives without examining the originating Sender's Email ID. This would
cause the Anti-spam tests to be performed.
b. As per the current Help Documentation for Whitelisting when specifying the Whitelisted Email ID or Domain for the IP Range specified if 'Forwarding Relay' is specified then hMailServer will use the Received Headers of the
email to determine the originating Email Id which in this case should have been 'TrackingUpdates@fedex.com'.

'•If you have selected "Forwarding relay" in the IP range the sender is connecting from, hMailServer will use the Received-headers of the email to determine the originating email IP address.'

c. I have looked at the Whitelist record information and the 'Forwarding Relay' specification does not appear in the Whitelist record as an available entry to be made.

Can anyone advise where the 'Forwarding Relay' selection is as this would appear to be the reason why the Anti-spam processing was not bypassed?

Posted: **2019-06-21 07:45**

The spam whitelist was probably missed because the SMTP envelope from didn't include the FROM address

It doesn't matter what the message headers say.

Was this a SPAM email or a Ham

Posted: **2019-06-21 08:52**

jim.bus wrote: ↑
2019-06-21 06:09
a. The Return Path in the Message Headers was 'prvs=4073a73a4e=bounce@nds.fedex.com'. hMailServer I believe examines the Message that it receives without examining the originating Sender's Email ID. This would
cause the Anti-spam tests to be performed.

this is true. BATV tagged envelope from address makes no sense to whitelist as it changes on every mail even from same person or service. you need to whitelist *@nds.fedex.com

jim.bus wrote: ↑
2019-06-21 06:09
b. As per the current Help Documentation for Whitelisting when specifying the Whitelisted Email ID or Domain for the IP Range specified if 'Forwarding Relay' is specified then hMailServer will use the Received Headers of the
email to determine the originating Email Id which in this case should have been 'TrackingUpdates@fedex.com'.

no, as i understand, HMS again reads envelope from address (prvs=...etc).

Posted: **2019-06-21 09:28**

mattg wrote: ↑
2019-06-21 07:45
The spam whitelist was probably missed because the SMTP envelope from didn't include the FROM address

It doesn't matter what the message headers say.

Was this a SPAM email or a Ham

This was a legitimate email NOT SPAM and one I was expecting to receive.

This portion of the email Message Headers was the first portion and apparently how the email originated that was sent to me:

From: TrackingUpdates@fedex.com
Reply-To: trackingmail@fedex.com

These lines above were in the Message Headers. The Return Path Email Id was apparently altered 2 or 3 times as it was relayed from server to server on the way to hMailServer as the final destination. The From: TrackingUpdates@fedex.com email id in the Message Headers only appeared this one time. This is why I thought the 'Forwarding Relay' selection on the Whitelist Record if the selection did exist as was documented in the Help Documentation would have handled this situation. But I cannot find this 'Forwarding Relay' selection that was documented. It seems this selection was designed to handle such a situation.

And Katip yes I realized *@nds.fedex.com would probably have been a workaround but the problem with that suggestion is I wouldn't have known this would be the Domain used on the Email ID as I didn't see what was used until after it had been sent and was marked SPAM by Anti-spam processing. Probably a better Whitelist Record would be *@*.fedex.com but then again I wouldn't necessarily know I would have to do that because the only Domain I knew of was fedex.com.

This is why the 'Forwarding Relay' selection if it really existed and did what the documentation seemed to indicate it did would seem to have accounted for this type of situation because the Help Documentation seemed to imply hMailServer would then look for the originating Email ID.

Posted: **2019-06-21 10:58**

jim.bus wrote: ↑
2019-06-21 09:28
And Katip yes I realized *@nds.fedex.com would probably have been a workaround but the problem with that suggestion is I wouldn't have known this would be the Domain used on the Email ID as I didn't see what was used until after it had been sent and was marked SPAM by Anti-spam processing. Probably a better Whitelist Record would be *@*.fedex.com but then again I wouldn't necessarily know I would have to do that because the only Domain I knew of was fedex.com.

This is why the 'Forwarding Relay' selection if it really existed and did what the documentation seemed to indicate it did would seem to have accounted for this type of situation because the Help Documentation seemed to imply hMailServer would then look for the originating Email ID.

whitelisting entire (sub)domains is not wise anyway. DHL and Fedex are 2 common phishing "From"s and indeed many of this spam have envelope from the same as visible From.
I was able to combat with them with the help of SA where you can define combined address + Received header terms. luckily both use their own systems for end-to-end SMTP and not that ...PROD.OUTLOOK.COM or alike crap. so, Received criteria in SA worked well. we receive legit mails, but x10 phishing too from DHL every day.
but with some scripting this could be achieved also in HMS i think.

btw, i also don't know about this "Forwarding relay" mentioned in docs.

Posted: **2019-06-21 11:07**

'Incoming relays' is used in the GUI

Let me know which page you saw 'forwarding relay', and I will change it.
It sounds like what 'incoming relay' does...

Posted: **2019-06-21 12:54**

jim.bus wrote: ↑
2019-06-21 06:09
b. SPF and DKIM tests were performed and the DKIM Test failed generating a SPAM Score of 5 for the failure.

Let's be honest. This is the real problem. DKIM can fail for many reasons. Setting such a high score for this results in tons of false positives. I unchecked DKIM as an hmailserver spam check ages ago.

Let spamassassin deal with DKIM.

Posted: **2019-06-21 13:44**

mattg wrote: ↑
2019-06-21 11:07
Let me know which page you saw 'forwarding relay', and I will change it.

https://www.hmailserver.com/documentati ... itelisting
older versions too..

Posted: **2019-06-21 14:23**

Can we clarify a few things here? (All examples are SPAM mails so feel free to carpet bomb the senders

and yes, all examples are different sessions )

- The setting "Incoming Relays" define how hMailServer interpret the "Received:" header

- Under normal circumstances hMailServer will use the connecting IP Address when doing RBL lookups.

Code: Select all

"SMTPD"	3108	296	"2019-06-21 13:46:17.062"	"185.171.233.38"	"RECEIVED: EHLO mail.kapsulsne.com"
"SMTPD"	3108	296	"2019-06-21 13:46:37.562"	"185.171.233.38"	"SENT: 250-mx.acme.inc[nl]250 SIZE"
"SMTPD"	3824	296	"2019-06-21 13:46:37.609"	"185.171.233.38"	"RECEIVED: MAIL FROM:<gerd@kapsulsne.com>"
"SMTPD"	3824	296	"2019-06-21 13:46:37.624"	"185.171.233.38"	"SENT: 250 OK"
"SMTPD"	3824	296	"2019-06-21 13:46:37.671"	"185.171.233.38"	"RECEIVED: RCPT TO:<wile.e.coyote@acme.inc>"
"SMTPD"	3824	0	"2019-06-21 13:46:37.734"	"TCP"	"DNS lookup: 38.233.171.185.zen.spamhaus.org, 0 addresses found: (none), Match: False"
"SMTPD"	3824	0	"2019-06-21 13:46:37.874"	"TCP"	"DNS lookup: 38.233.171.185.b.barracudacentral.org, 0 addresses found: (none), Match: False"
"SMTPD"	3824	0	"2019-06-21 13:46:37.968"	"TCP"	"DNS lookup: 38.233.171.185.bl.spamcop.net, 0 addresses found: (none), Match: False"
"SMTPD"	3824	296	"2019-06-21 13:46:37.968"	"185.171.233.38"	"SENT: 250 OK"
"SMTPD"	3824	296	"2019-06-21 13:46:38.030"	"185.171.233.38"	"RECEIVED: DATA"
"SMTPD"	3824	296	"2019-06-21 13:46:58.515"	"185.171.233.38"	"SENT: 354 OK, send."
"SMTPD"	3488	296	"2019-06-21 13:47:02.233"	"185.171.233.38"	"SENT: 250 Queued (3.688 seconds)"
"SMTPD"	1152	296	"2019-06-21 13:47:02.296"	"185.171.233.38"	"RECEIVED: QUIT"
"SMTPD"	1152	296	"2019-06-21 13:47:02.296"	"185.171.233.38"	"SENT: 221 goodbye"

- However if an "Incoming Relay" is defined hMailServer will look to the "Received:" header

Code: Select all

Received: from backup-mx.post.tele.dk (backup-mx1.post.tele.dk [80.160.77.99]) by mx.acme.inc
 ; Mon, 17 Jun 2019 18:00:33 +0200
Received: from mail.absoluteswords.com (absoluteswords.com [185.171.233.57]) by
 backup-mx.post.tele.dk (Postfix) with ESMTP id 58A268540D0 for <wile.e.coyote@acme.inc>;
 Mon, 17 Jun 2019 16:44:28 +0200 (CEST)

- and the log will change to this.

Code: Select all

"SMTPD"	1524	284	"2019-06-21 13:41:09.410"	"80.160.77.115"	"RECEIVED: EHLO backup-mx.post.tele.dk"
"SMTPD"	1524	284	"2019-06-21 13:41:09.425"	"80.160.77.115"	"SENT: 250-mx.acme.inc[nl]250 SIZE"
"SMTPD"	1524	284	"2019-06-21 13:41:09.457"	"80.160.77.115"	"RECEIVED: MAIL FROM:<cherry@railcarbow.icu>"
"SMTPD"	1524	284	"2019-06-21 13:41:09.457"	"80.160.77.115"	"SENT: 250 OK"
"SMTPD"	1524	284	"2019-06-21 13:41:09.488"	"80.160.77.115"	"RECEIVED: RCPT TO:<wile.e.coyote@acme.inc>"
"SMTPD"	1524	284	"2019-06-21 13:41:09.488"	"80.160.77.115"	"SENT: 250 OK"
"SMTPD"	1524	284	"2019-06-21 13:41:09.503"	"80.160.77.115"	"RECEIVED: DATA"
"SMTPD"	1524	284	"2019-06-21 13:41:09.503"	"80.160.77.115"	"SENT: 354 OK, send."
"SMTPD"	3488	0	"2019-06-21 13:41:09.660"	"TCP"	"DNS lookup: 25.171.252.89.zen.spamhaus.org, 0 addresses found: (none), Match: False"
"SMTPD"	3488	0	"2019-06-21 13:41:09.800"	"TCP"	"DNS lookup: 25.171.252.89.b.barracudacentral.org, 0 addresses found: (none), Match: False"
"SMTPD"	3488	0	"2019-06-21 13:41:09.972"	"TCP"	"DNS lookup: 25.171.252.89.bl.spamcop.net, 0 addresses found: (none), Match: False"
"SMTPD"	3488	284	"2019-06-21 13:41:12.081"	"80.160.77.115"	"SENT: 554 5.3.0 [Origin Banned] The SMTP service originating on IP address (89.252.171.25) is not welcome here."
"SMTPD"	1524	284	"2019-06-21 13:41:12.175"	"80.160.77.115"	"RECEIVED: QUIT"
"SMTPD"	1524	284	"2019-06-21 13:41:12.175"	"80.160.77.115"	"SENT: 221 goodbye"

- You will notice that the IP Address being looked up (89.252.171.25) is different from the connecting IP Address (80.160.77.115).
I have not had any reason (yet) to test how deep this can functionality be nested.

- The whitelisted email address I have so far found to be the "Envelope From" AKA the "MAIL FROM:<cherry@railcarbow.icu>" from the example above.

I have used this functionality since I first learned about it - probably 10 years or so - and I expect it to continue to function the way I am used to.

I made a simple test by having my gmail account forward mails to my hmailserver account. If I send directly from gmail my "Envelope From" = "mygmail@gmail.com", when gmail forward my mail back to me the "Envelope From" = "mygmail+caf_=wile.e.coyote=acme.inc@gmail.com".
If I add "mygmail+caf_=wile.e.coyote=acme.inc@gmail.com" to the whitelist all forwarded emails are whitelisted and emails sent diretly from "mygmail@gmail.com" are not.

Whitelisting an IP Range (or single IP Address) I have not yet had the use for since I control that in my "IP Ranges" settings. If the Whitelist IP Address range only cover the specified email address I have no knowledge of. Someone perhaps could test this.

I have a vague recollection that being on the Whitelist also exempt the email from virus checking and attachment blocking. Can someone verify this?

EDIT: Whitelist entries with BOTH an IP Range AND an email address will ONLY be whitelisted if email address is inside IP Range. If email received via Incoming Relay NO whitelisting is done.

Posted: **2019-06-21 15:16**

jim.bus wrote: ↑
2019-06-21 06:09
Can anyone advise where the 'Forwarding Relay' selection is as this would appear to be the reason why the Anti-spam processing was not bypassed?

https://www.hmailserver.com/documentati ... =changelog

5.1 Alpha Build 327 (2009-02-02)

The "Forwarding relay" option is no longer a setting in IP ranges but instead stored separately as "Incoming relays". The settings are found next to the IP ranges in hMailServer Administrator and WebAdmin. This change was made partly because the term "Forwarding relay" was a bit confusing and partly to improve performance.

There you go.

So what you have learnt is:

if the incoming email is in an ip range that is covered by 'Incoming Relay' then the RECEIVED HEADRS will be used (and maybe they dont match what you have entered in your whitelist)

OR (probably)

you whitelisted @fedex.com when in reality the smtp envelope is being passed a message from @nds.fedex.com (which is NOT a match). You will need to whitelist @nds.fedex.com (OR "@*fedex.com" and hope you dont get spam from "user@IwantToBefedex.com"

)

Posted: **2019-06-22 01:19**

katip wrote: ↑
2019-06-21 13:44

mattg wrote: ↑
2019-06-21 11:07
Let me know which page you saw 'forwarding relay', and I will change it.
https://www.hmailserver.com/documentati ... itelisting
older versions too..

I can only change 'latest' page, but done.
Thanks for the link

Posted: **2019-06-22 01:35**

SorenR wrote: ↑
2019-06-21 14:23
Whitelisting an IP Range (or single IP Address) I have not yet had the use for since I control that in my "IP Ranges" settings. If the Whitelist IP Address range only cover the specified email address I have no knowledge of. Someone perhaps could test this.

I have a vague recollection that being on the Whitelist also exempt the email from virus checking and attachment blocking. Can someone verify this?

EDIT: Whitelist entries with BOTH an IP Range AND an email address will ONLY be whitelisted if email address is inside IP Range. If email received via Incoming Relay NO whitelisting is done.

From my understanding Whitelisting relies on the connected IP address. If you whitelist the incoming relay IP address it should whitelist as normal

Virus checking still occurs on whitelisted email - whitelisting is after all a AntiSPAM setting
SpamAssassin checking does not occur. Normal events still occur and any spam scoring that happens with scripts is still applied.

All of my REAL whitelist entries have IP range settings of 0.0.0.0 to 255.255.255.255, it is the email address that is whitelisted. I too use IP ranges to limit / grant access from specific IP addresses - and these are still tested for spam

Posted: **2019-06-22 05:14**

why would you whitelist a relay? By defining it as a relay you imply that it is safe and hMailServer should therefore ignore it in the process.

Posted: **2019-06-22 06:29**

I don't consider incoming relays as safe.

I have a server in my incoming relays list that is a list server. It doesn't do the forwarding correctly, and unless I include it in my incoming relays list, it triggers my SPF, DKIM & DNSBL antispam settings.

By setting it as an incoming relay, hMailserver looks for IP addresses in received headers, and uses that for SPF, DKIM and DNSBL checks.

Posted: **2019-06-22 10:20**

mattg wrote: ↑
2019-06-22 06:29
I don't consider incoming relays as safe.

I have a server in my incoming relays list that is a list server. It doesn't do the forwarding correctly, and unless I include it in my incoming relays list, it triggers my SPF, DKIM & DNSBL antispam settings.

By setting it as an incoming relay, hMailserver looks for IP addresses in received headers, and uses that for SPF, DKIM and DNSBL checks.

Aha... I do not regard a list-server a relay. They certainly did not function that way when we played with them back in the 80's on EARN and BITNET

I've had my Backup-MX'es listed as the only Relays for the past 10+ years.

Posted: **2019-06-22 10:30**

SorenR wrote: ↑
2019-06-22 05:14
why would you whitelist a relay? By defining it as a relay you imply that it is safe and hMailServer should therefore ignore it in the process.

Exactly that.

I use an incoming relay. As such it is automatically whitelist/ exempted from spam checking. I set it as such exactly for the reason that the relay was always being checked muddying the water. As a relay it now gets completely ignored.

[Entered by mobile. Excuse my spelling.]

Posted: **2019-06-22 11:07**

I checked my logs

Mail coming via incoming relays definitely get spam checked

Posted: **2019-06-22 11:09**

Another matter... There is a flaw in the "Incoming Relay" code. If the relayed message is coming from a banned server the message is allowed through.

Well, not on my server! The code is designed to handle my Backup-MX which is a 3 server Round Robin set-up that all identify as "backup-mx.post.tele.dk" thus a multiple "Incoming Relay" setup will need to rewrite Function XServer.

Code: Select all

Private Const BACKUPMX = "backup-mx.post.tele.dk"

'
'   NOTE! A number of "support" Functions are not included for clarity
'

Function XServer(oClient, oMessage)
   Dim i, a, strRegEx, oMatch, oMatches
   If Lookup("from " & BACKUPMX, oMessage.HeaderValue("Received")) Then
      For i = 0 To oMessage.Headers.Count-1
         If (oMessage.Headers(i).Name = "Received") Then
            If Lookup("by " & BACKUPMX, oMessage.Headers(i).Value) Then
               a = Split( oMessage.Headers(i).Value, " " )
               oMessage.HeaderValue("X-Envelope-HELO") = Trim(a(1))
               strRegEx = "(?:[0-9]{1,3}\.){3}[0-9]{1,3}"
               Set oMatches = oLookup(strRegEx, oMessage.Headers(i).Value, False)
               For Each oMatch In oMatches
                  oMessage.HeaderValue("X-Envelope-IPAddress") = Trim(oMatch.Value)
               Next
               oMessage.Save
               Exit For
            End If
         End If
      Next
   Else
      oMessage.HeaderValue("X-Envelope-HELO") = Trim(oClient.HELO)
      oMessage.HeaderValue("X-Envelope-IPAddress") = Trim(oClient.IPAddress)
      oMessage.Save
   End If
   Set oMatches = Nothing
End Function

Function isBanned(oMessage) : isBanned = False
   Dim a, strIP, strLowerIP, strUpperIP, strRegEx, oMatch, oMatches
   If (oMessage.HeaderValue("X-Envelope-HELO") <> "") Then
      strRegEx = GetXMLNode(XMLDATA, "//Reject/HELO")
      Set oMatches = oLookup(strRegEx, oMessage.HeaderValue("X-Envelope-HELO"), False)
      For Each oMatch In oMatches
         isBanned = True
         Set oMatches = Nothing
         Exit Function
      Next
   End If
   Dim oApp : Set oApp = CreateObject("hMailServer.Application")
   Call oApp.Authenticate(ADMIN, PASSWORD)
   strIP = ip2num(oMessage.HeaderValue("X-Envelope-IPAddress"))
   For a = 0 To oApp.Settings.SecurityRanges.Count-1
      If (oApp.Settings.SecurityRanges.Item(a).Priority = 20) Then
         strLowerIP = ip2num(oApp.Settings.SecurityRanges.Item(a).LowerIP)
         strUpperIP = ip2num(oApp.Settings.SecurityRanges.Item(a).UpperIP)
         If (strUpperIP >= strIP) And (strIP >= strLowerIP) Then
            isBanned = True
            Set oApp = Nothing
            Set oMatches = Nothing
            Exit Function
         End If
      End If
   Next
   Set oApp = Nothing
   Set oMatches = Nothing
End Function

Sub OnAcceptMessage(oClient, oMessage)
   '
   '   Add more X-Envelope... headers
   '
   Call XServer(oClient, oMessage)
   Client_IP = oMessage.HeaderValue("X-Envelope-IPAddress")
   Client_HELO = oMessage.HeaderValue("X-Envelope-HELO")
   '
   '   Check for banned sender via Backup-MX ?
   '
   If (oClient.IPAddress <> Client_IP) Then
      If isBanned(oMessage) Then
         Result.Value = 2
         Result.Message = "5.3.0 [Origin Banned] The SMTP service originating on IP address (" & Client_IP & ") is not welcome here."
         EventLog.Write( LPad("isBanned", 15, " ") & vbTab & LPad(oClient.IPAddress, 16, " ") & vbTab & LPad(Client_IP, 16, " ") & vbTab & Client_HELO )
         Exit Sub
      End If
   End If
End Sub

Posted: **2019-06-22 11:18**

mattg wrote: ↑
2019-06-22 11:07
I checked my logs

Mail coming via incoming relays definitely get spam checked

Yes, that is the functionality we want. If you did not define the server as a relay it would be the Relay IP Address that would be checked, not the relayed message.

A write a letter to B, B cannot receive directly so A deliver letter to C to deliver to B.
Normally B would regard C the source to pass securty as C deliver the physical letter, BUT!
If C is defined "a relay"/"the messenger" then B would regard A the source to pass security.

Which means the prase "don't shoot the messenger" has some validity

Posted: **2019-06-22 11:33**

@mattg

I would love to see the complete headers from a list-serv message that is causing you problems.

Posted: **2019-06-23 00:14**

Sent a couple of samples via PM

This is due to lack of SRS I think on the list server

Posted: **2019-06-23 03:32**

mattg wrote: ↑
2019-06-21 11:07
'Incoming relays' is used in the GUI

Let me know which page you saw 'forwarding relay', and I will change it.
It sounds like what 'incoming relay' does...

I can't locate that page now. The Help Documentation I see now uses the term 'Incoming Relay' as well under the documentation for 'Whitelisting'. However in my posting above the bulleted example I referred to was directly copied from the Help Documentation I saw it on and the only difference as best I can recall is that it used the term 'Forwarding Relay'.

I did see somewhere also a Help Documentation page which was shown as 'Anti-spam Whitelist' and the term 'Forwarding relay' was on it as well but again now I cannot locate that page either.

Posted: **2019-06-23 04:24**

All good and thanks for checking
You probably had the page that I've already changed.

Posted: **2019-06-25 03:29**

mattg wrote: ↑
2019-06-23 04:24
All good and thanks for checking
You probably had the page that I've already changed.

That is what I was thinking as the page I now look on is identical to the page I saw the 'Forwarding Relay' selection shown on in the Notes except that 'Forwarding relay' now says 'Incoming relay' which is the page you indicated you previously changed.

hMailServer forum

hMailServer B2425 Anti-spam Whitelisting Failure

hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure

Re: hMailServer B2425 Anti-spam Whitelisting Failure