Syntax for Greylistingfilter (Blac-/Whitelist)

[Flachzange]

ah ok, now I get what you have meant with "effectiveness". You're right, greylisting of course has a couple of conceptual flaws.

PS By the way, your facebook issue is likely due to the missing wildcard: try *facebookmail.com

see the whiteliste above. I have

facebookmail.com
*facebookmail.com
*tfbnw.net
tfbnw.net

in my whitelist. I really assume that this is related to the same issue as the weird blacklisting problem reported at the beginning of this thread.

 

[trialotto]

ah ok, now I get what you have meant with "effectiveness". You're right, greylisting of course has a couple of conceptual flaws.



see the whiteliste above. I have

facebookmail.com
*facebookmail.com
*tfbnw.net
tfbnw.net

in my whitelist. I really assume that this is related to the same issue as the weird blacklisting problem reported at the beginning of this thread.

Sorry, it was kind of late and I did not see the other "facebook entry".

However, your reaction has triggered some strange intuition: can you try *@facebookmail.com on the domains whitelist? I am pretty sure that you will not have any DEFER messages. If so, this makes a focus possible: the error then is on the server-wide white-/blacklist handling.

Please post results.

NOTE: I am not having any trouble with blacklists (do you?). This suggests that something strange happens with the whitelist in your machine. If i can replicate the error, we then have an official bug (I was not able to replicate though).

 

[Flachzange]

the problem still exists...

White domains patterns list:
fmmailgate*.web.de
*.rzone.de
mxpool*.ebay.com
mxphxpool*.ebay.com
*.amazon.com
*.obsmtp.com
mail*.google.com
mailout*.t-online.de
mail.gmx.net
pmt.perfora.net
memailout*.messagereach.com
smtpsrv*.fagms.de
smtp*.netcologne.de
mailgate.db-group.com
mail*.srv2.de
*.rz.ruhr-uni-bochum.de
*.paypal.com
*.rz.RWTH-Aachen.DE
*.alpha.ec-cluster.com
mout*.freenet.de
mta.em.mathworks.com
smtprelay*.ispgateway.de
moutng.kundenserver.de
*facebookmail.com
mx.newstroll.de
*-out-*.google.com
*.emirates.com
*tfbnw.net
tfbnw.net
facebookmail.com
*@facebookmail.com

Nov 3 19:41:52 hostname relaylock: /var/qmail/bin/relaylock: mail from 69.63.178.183:34769 (outmail024.snc1.tfbnw.net)
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: Handlers Filter before-queue for qmail started ...
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: [email protected]
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: [email protected]
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: hook_dir = '/opt/psa/handlers/before-queue'
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: recipient[3] = '[email protected]'
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: handlers dir = '/opt/psa/handlers/before-queue/recipient/[email protected]'
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: call_handlers: call executable = '/opt/psa/handlers/info/05-grey-6It4LH/executable'
Nov 3 19:41:53 hostname greylisting filter[29701]: Starting greylisting filter...
Nov 3 19:41:53 hostname greylisting filter[29701]: Timeout finished
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: handlers_stderr: SKIP
Nov 3 19:41:53 hostname qmail-queue-handlers[29700]: call_handlers: SKIP during call '/opt/psa/handlers/info/05-grey-6It4LH/executable' handlerr

Please not that we have a SKIP because the greylisting triple was already known, not because it is whitelisted.

Anyway, the domain patterns refer to the domain of the sending mail server (tfbnw.net), not to the domain of the e-mail address (facebook.com).

Ok lets summarize the problem, which I try to explain in this whole thread:
First, I am asking for the syntax of the greylisting's black- and whitelist domain patterns, because I noticed, that some mails are not blacklisted, although they should have been. I was asking if the patterns are regular expression (because they look similiar). I still do not have an answer on this question, but it seems that they are not. I tried several RegExp to blacklist IPs, but without success. If I could blacklist all incoming mail servers which do not have a reverse DNS name, I could block a lot of spam in advance. Then with facebook, I finally had an example which exposes the very same problem with whiteliste filtering as have it with the earlier descibed blacklist (The patterns are not applied). So at least I would claim that there is an issue with applying patterns to reverse DNS names (or anything else which can be resolved to an IP address) of the sending mail servers!

Christoph

 

[trialotto]

Final remarks

Christoph,

Naturally: do NOT put the *@<domain>.tld in the domains white list. It does NOT belong there.

Naturally: you get a SKIP, due to a match in the domains white list (in this case, the exact match is *tfbnw.net).

And SURE: there is an issue with reverse DNS.

But you only mention a minor flaw (not a bug or issue/problem with the filter), with this flaw being that (to my best knowledge) the greylisting filter only uses "reverse DNS" (rDNS) and does not use the theoretically better "Forward Confirmed reverse DNS" (FCrDNS).

For a better understanding of rDNS: see http://en.wikipedia.org/wiki/Reverse_DNS_lookup
For a better understanding of FCrDNS: see http://en.wikipedia.org/wiki/Forward_Confirmed_reverse_DNS

Then again, note that you can resolve this flaw by just adding specific DNSBL services (in plesk control panel, just allow for "spam protection based on DNS blackhole lists" under "mail server settings").

That blocks a huge amount of spam in advance. In practice, as confirmed by many tests executed by me, proper DNSBL configuration makes the greylisting filter almost obsolete in the server-wide environment.

The value of the greylisting filter comes from the fact that it delivers the feature of individual settings in the domain-specific and mailbox-specific environment, due to the tight integration with spamassassin. The filter simply adds the possibility to extend the DNSBL settings to your own liking.

The DNSBL services should preferably be zen.spamhaus.org. Do not use spamcop, even though it uses the "stronger" FCrDNS check, since spamcop can (and will) cause problems.

It is very likely that Parallels, in order to prevent those problems with FCrDNS, is making use of the simple rDNS check.

The drawbacks of this check and therefore the inherent drawbacks of the greylisting filter can cause the behavior that did start this thread. However, these drawbacks are certainly not causing the behavior automatically.

Finally, I was never able to replicate similar errors, caused by white-/blacklist patterns.

In short, patterns are used correctly and whatever errors there might be with rDNS: those errors can be resolved by using DNSBL services

 

[Flachzange]

Honestly said, I am getting tired of explaining the problem in every single post in this thread again and again and still have the feeling of not being understand.

Naturally: do NOT put the *@<domain>.tld in the domains white list. It does NOT belong there.

of course not, but you told me to add this as none of the other entries work

Naturally: you get a SKIP, due to a match in the domains white list (in this case, the exact match is *tfbnw.net).

exactly and the syslog entry would similar to this, but it is oviously not:

Oct 17 07:43:20 hostname greylisting filter[19914]: Starting greylisting filter...
Oct 17 07:43:20 hostname greylisting filter[19914]: list type: white, from: mail.gmx.net, match string: mail\.gmx\.net
Oct 17 07:43:20 hostname qmail-queue-handlers[19913]: handlers_stderr: SKIP
Oct 17 07:43:20 hostname qmail-queue-handlers[19913]: call_handlers: SKIP during call '/opt/psa/handlers/info/05-grey-6It4LH/executable' handler

But you only mention a minor flaw (not a bug or issue/problem with the filter), with this flaw being that (to my best knowledge) the greylisting filter only uses "reverse DNS" (rDNS) and does not use the theoretically better "Forward Confirmed reverse DNS" (FCrDNS).

I not sure what kind of flaw do you call minor, but neither the blacklist nor the whitelist works properly in my case. It might not be a critical bug, but something which definitely should be addressed by the developers.

Then again, note that you can resolve this flaw by just adding specific DNSBL services (in plesk control panel, just allow for "spam protection based on DNS blackhole lists" under "mail server settings").

I know about DNSBL and I decided not to use it. And by the way, this has nothing to do with the above stated problems! Simply using another Spamfilter-Method ist NOT the solution!

I really appreciate your efforts on this topic, but as long as no one really takes my problem seriously, I will not waste any additional time on this.

Regards,
Christoph

 

[Magumo]

Whitelisting IP address

Good day,

I have a case of a school mail server sending emails from a server without a FQDN and as a result the emails are bouncing to my server.

Feb 5 09:02:22 srv greylisting filter[2069]: Starting greylisting filter...
Feb 5 09:02:22 srv greylisting filter[2069]: list type: black, from: [196.x.x.4], match string: .*[0-9][0-9].[0-9][0-9].[0-9][0-9].*

I have attempted to whitelist the IP server-wide but the emails are still bouncing. Below is my grey_listing -i partially output.

Server-wide white list:

White domains patterns list:
*google.com
*mail.ru
*parallels.com
*rambler.ru
*yahoo.com
*yandex.ru
196.x.x.4

Black domains patterns list:
*[0-9][0-9]-[0-9][0-9]-[0-9][0-9]*
*[0-9][0-9].[0-9][0-9].[0-9][0-9]*
*[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]*
*[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9[0-9]][0-9]*
dsl|pool|broadband|hsd
dynamic|static|ppp|dyn-ip|dial-up

SUCCESS: Gathering of server wide information complete.

I still want to maintain the whole blacklist with just my IP whitelisted.

Please help.

 

[trialotto]

The main mistake is to add the IP adress, since the filter does a reverse DNS lookup and filters by DNS (not the IP).

You are therefore instructing the greylisting filter to allow (whitelist) mail that comes from the domain 196.x.x.4 and not to allow mail from the IP 196.x.x.4.

So, first remove that entry!

In the below, I assume you can not change the FQDN of the sending mail server. In your case, that is also a problem.

In normal scenario's, the absence of FQDN or domain name is an indication that the sending mail server is a relay or a mail server that is vulnerable to mail injections (intended to relay unauthorized spam).

Your greylisting filter is doing its work and there should be no desire to change settings (in the blacklist) for the sake of the sending mail server (school server).

Therefore, try to find domain information! (for example on www.domaintools.com, or ) If something is found, add the domains to your whitelist.

If you cannot find anything, please mail me the IP address and additional information....

 

[Magumo]

Trialotto,

I have added the domain already in the whitelist but still the blacklist is kicking in.

Server-wide white list:

White domains patterns list:
*google.com
*mail.ru
*parallels.com
*rambler.ru
*yahoo.com
*yandex.ru
196.44.34.34
domain.co.za

Emails from that domain are still being blacklisted.

 

[trialotto]

maqumo,

Try to remove the IP adress (196.xx.xx.xx) and the "domain.co.za" entries from the domain white list. Note that the domain.co.za entry should be of the form *domain.co.za.

In order to have spamassassin filter and greylisting filter to work optimal and work together, you should add an entry to the normal whitelist. Command:

./grey_listing -u -whitelist add:*@domain.co.za

The optional entry in the domains white list (no harm when doing so) can be achieved with the command:

./grey_listing -u -domains-whitelist add:*domain.co.za

Both commands result in proper entries.

If these entries do not yield the desired results, then it is very likely that nothing can be done since something is very wrong in the DNS of the sending mail server.

Let me know if it works!
Furthermore, it is even more wise to add the entry *@domain.co.za to your

 

[Magumo]

Only FQDN will work

Try to remove the IP adress (196.xx.xx.xx) and the "domain.co.za" entries from the domain white list. Note that the domain.co.za entry should be of the form *domain.co.za.

Removed.

In order to have spamassassin filter and greylisting filter to work optimal and work together, you should add an entry to the normal whitelist. Command:

./grey_listing -u -whitelist add:*@domain.co.za

Added.

The optional entry in the domains white list (no harm when doing so) can be achieved with the command:

./grey_listing -u -domains-whitelist add:*domain.co.za

Added.

Furthermore, it is even more wise to add the entry *@domain.co.za to your

Done.

At this point I am engaging the school server administrator to configure a proper FQDN on the server. IP whitelisting is not possible. Thanks a lot trialotto for your help.

 

[Magumo]

Does domain.local on Exchange qualify as FQDN??

In normal scenario's, the absence of FQDN or domain name is an indication that the sending mail server is a relay or a mail server that is vulnerable to mail injections (intended to relay unauthorized spam).

It turns out the school is using adminsrv.domain.local as the FQDN. Is that name a valid FQDN or it should be some DNS resolvable domain name?

Please help.

 

[trialotto]

Maqumo,

The issue here is that you should allow proper mail adresses. That is, the mail adresses should correspond to a domain name that is resolvable.

In every way, a FQDN should be resolvable, since it is linked to the IP of the server machine.

However, the real question is not concerning the FQDN. The question that should be asked is: what is the domain name from which the mails are being send? For example, [email protected] has the domain name domain.tld and this domain name should be (DNS) resolvable. This domain name can be used for grey listing purposes.

This specific domain name should be found.....

I suggest you contact the schools admin to find out which domain name they are using.

If any questions, please contact me by mail (let us keep the thread as clean as possible)