We have some Problems with Mails from one web (web15) to an other web (web20) on one Server. Bothe webs belong to one Company but two Locations who Exchange a lot of Mails. Most of them are marked as Spam. In one Location there is Groupware-Server (Tobit) on an dynamic IP DSL Connection. On the other Location are Outlook-Clients who send directly over an dynamic IP DSL Connection. This is theSpamAssasin Report of one Mail: Content analysis details: (8.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.3 TVD_RCVD_IP4 TVD_RCVD_IP4 1.6 TVD_RCVD_IP TVD_RCVD_IP 0.0 HTML_MESSAGE BODY: HTML included in message 1.8 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 1.6 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [84.169.38.131 listed in dnsbl.sorbs.net] 0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [84.169.38.131 listed in zen.spamhaus.org] -0.0 AWL AWL: From: address is in the auto white-list Why are those Mails get their IPs checked? (These Clients connect directly to our Server. I thought Clients authenticated by our Server doesn't need to be scanned.) Why do the AWL score -0.0? (In http://www.howtoforge.com/forums/showthread.php?t=9745 you discussed about the "score AWL -100.0" and these setting is set to -100 in our configs.) Is their anything i can do to improve the E-Mail settings? Thanks a lot for yor help.
Is the mail server using a dynamic IP address? This thread might help you as well: http://www.howtoforge.com/forums/showthread.php?t=13815&highlight=spam
No, our Mailserver has static IP address and Reverse DNS. I even checked our address in SORBS and it is not listed. The IP address in the SpamAssasin Reports are the IP adresses of our Costumers. They are dynamic. Why does SpamAssasin check these IP's because they authenticate themselves to Postfix?
Did you try the suggestions from this thread? http://www.howtoforge.com/forums/showthread.php?t=13815&highlight=spam
If i add "skip_rbl_checks 1" to "/home/admispconfig/ispconfig/tools/spamassassin/etc/mail/spamassassin/local.cf" does it disable the RBL-Checks globally or only for incoming mail from local users?
I read some posts in the Mailinglist mentioned in the other thread and found a Mail regarding a Sendmail macro to filter the Mails from local Users which use SMTP AUTH. http://lists.roaringpenguin.com/pipermail/mimedefang/2003-October/017522.html Is there a way to implement a similar filter for Postfix and ISPConfig?
I had the same problem once, and only "fixed" it by skipping the rbl checks. If SA would no be started via procmail but e.g. via clamav (out of postfix), you could tell postfix to not use SA for mails incominfg via smtp-auth (587 or sth. like this). But this is not possbile here. So what you would have to do is change _all_ (of every user) procmail scripts that run SA and change it the way to not run SA for authenticated users. -> http://www.howtoforge.com/forums/showthread.php?t=13815
How could i do that? In this Thread you posted to insert "skip_rbl_checks 1" in "/home/admispconfig/ispconfig/tools/spamassassin/etc/mail/spamassassin/local.cf". Does this disable it only for Mails from authenticated users and not for all Mails?
Find the template for .user_prefs in /root/ispconfig/isp/conf and place your modified version in the /root/ispconfig/isp/conf/customized_templates directory. Then change something in ISPConfig for all users. The .user_prefs file will then be rewritten for all users.
You could also correctly set up spamassassin's trusted and internal network lists. Then it will at least be flagged "ALL_TRUSTED".
Thank you for this Info. There was a little missunderstanding. I want to know what i have to change in the procmail scripts so that only mails from authenticated users where skipped in Spamfiltering.
Ever tried sending an authenticated mail to yourself to check??? Newer versions of Postfix for example can add an extra header http://www.postfix.org/postconf.5.html#smtpd_sasl_authenticated_header
sounds good, so one could check that header in the procmail.... but how can we make sure then, that nobody sending a mail from another server is setting this header as well? Well just checked the switch, it generated an output like So which way could be the best to verify that? I mean each procmailscript has either to filter and check that name against the virtualusertable or to know all usernames. Next would be to remove that header (if possible), to hide that from others, receiving such a mail...
Yup, that I cannot tell you on the fly now exactly either. Here is a site from Spamassassin discussing such issues http://wiki.apache.org/spamassassin/DynablockIssues Anyway, once this header is seen, one is added to the AWL (auto white list). If other checks, and if yes, which ones, are executed would be a good question too. I configured and knew this once but I do not remember. I love paranoia Maybe there is a real crack here who can answer that, but I can't right now. ADDED: I must reiterate you should in any case have trusted and internal network list configured right in SA!
This (of course) does not let me sleep Therefore I have looked up the following in Spamassassin documentation * If the 'from' host has an IP address in a private (RFC 1918) network range, then it's trusted * If there are authentication tokens in the received header, and the previous host was trusted, then this host is also trusted * Otherwise this host, and all further hosts, are consider untrusted. http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html A tip from myself: Either set internal_networks OR trusted_networks in spamassassin config, except you know exactly what you are doing! Conclusion: no matter what header the "evil people" add, if the chain of trust is not extended to their machine (i.e. their received header), it will not help. However, if you add custom headers to your mail (like X-Auth-blablabla: yes) prepare for others to just write this into their headers, as no MTA will touch them. In the end you could then set the ALL_TRUSTED rule to a large negative value. So that even when spam is sent a large number will be subtracted again from the score.
But which sense does it make to add trusted networks, if my customers will use any ISP the have. Beside that, due to the fact my server has an official IP Address, I ordered even it's firewall to drop access from priavte IPs, cause this would be illogic because they are not routed in the itnernet. So the question is will SA detect the header added by postfix when sending via smtp_auth, right and trust that host or do I have to change the procmail script to not even run SA then.
The interesting stuff about trust is in sub parse_received_headers() in /usr/share/perl5/Mail/SpamAssassin/Message/Metadata/Received.pm # So, what's the difference between a trusted and untrusted Received header? # Basically, relays we *know* are trustworthy are 'trusted', all others after # the last one of those are 'untrusted'. # # We determine trust by detecting if they are inside the network ranges # specified in 'trusted_networks'. # # The first Received line that you don't ignore is the one that # contains the "by" of your trusted relay and the "from" of the first # untrusted relay (which is used for bondedsender testing and so on). # # if we find authentication tokens in the received header we can extend # the trust boundary to that host Delivered-To: bla Received: from trusted_host by another_trusted_host Received: from dialup (...) by trusted_host <== CHECKED dialup is trusted if it contains f.e. an "authenticated" header by trusted_host, otherwise untrusted. You can't fake it (and suppose it is not faked) because you trust/control trusted_host. (You could also use pop-before-smtp, see POPAuth SA module, to infer trust to dialup) Yes I guess you can ignore that. Actually none of the points apply here if I read it again. The setup we are having is too simple So the answer is: yes, if your own hosts have correct trust set, then this will work. ADDED: That said, ISpconfig should probably update /home/admispconfig/ispconfig/tools/spamassassin/etc/mail/spamassassin/local.cf to include "trusted_networks xxx" where xxx is a space delimited list of all the ips/networks on the current machine (including 127.0.0.1 to be on the safe side)
