Page 2 of 3

Re: bypass spamassassin on ongoing messages

Posted: Wed Feb 10, 2010 4:42 am
by biggles
I'm only getting the encrypted part when I use SSL and access the server via port 465

Re: bypass spamassassin on ongoing messages

Posted: Wed Feb 10, 2010 10:47 am
by faris
zeki wrote:That's what I tryed... Then it matches on every incoming mail... with -10 point.....
Hmmm... I see the problem, yes.

The hostname is not actually getting in the right place. It is just the PTR on the IP.

Faris.

Re: bypass spamassassin on ongoing messages

Posted: Wed Feb 10, 2010 4:09 pm
by Galactic Zero
Just wanting to make this clear in my own mind, only a PTR record for the main server IP is necessary yes? so if my server name is gz.galacticzero.net then the PTR should be set to that or to my main doamin www.galacticzero.net?

Any other PTR records for other domains hosted should then be removed, correct?

Thanks.

Re: bypass spamassassin on ongoing messages

Posted: Wed Feb 10, 2010 4:52 pm
by faris
correct!

(if you have more than one IP, there should be a PTR for each of those IPs too - set in the dns for the exclusive domain, or default domain, for those IPs. But only the IP used to send email, which is usually the main or first one, absolutely 100% needs a PTR)

Faris.

Re: bypass spamassassin on ongoing messages

Posted: Wed Feb 10, 2010 7:27 pm
by breun
faris wrote:But only the IP used to send email, which is usually the main or first one, absolutely 100% needs a PTR
But that record doesn't necessarily need to be on your local nameserver. I think in a lot of cases the datacenter ISP owns the block of IP addresses and they should have a correct PTR record for your IP address. A good ISP will offer a control panel to configure this. Only when you manage your own IP addresses should you have any PTR records at your own nameservers, right?

Re: bypass spamassassin on ongoing messages

Posted: Thu Feb 11, 2010 10:07 am
by faris
Yes and no.

Remember that anything running on the Plesk server will use local DNS lookups, and will find the PTRs set up via Plesk/Bind. This is why having loads or PTRs (one for each domain) causes problems because one get picked at random to put in the email headers.

So while external lookups will get the PTR from the co-lo/hosting co/isp in charge of the IPs, the server itself will look at the local DNS records.

Faris.

Re: bypass spamassassin on ongoing messages

Posted: Thu Feb 11, 2010 10:43 am
by breun
I'm not 100% sure about this, but I believe it will still work fine if you don't have the PTR configured at your local nameserver. A lookup will be done and the reversed name will be found the nameserver that has the PTR record. And your local nameserver will cache that.

Re: bypass spamassassin on ongoing messages

Posted: Fri Feb 12, 2010 8:16 am
by faris
I didn't think of that! That would effectively remove the in-arpa record completely, wouldn't it. I think you are right.

Faris.

Re: bypass spamassassin on ongoing messages

Posted: Fri Feb 12, 2010 8:34 am
by zeki
hello peoples
when we go back to the problem in the topic... ;-)

when i have the rules active, my incoming mails gets too -10 points.

whats with your configurations?

thanks
zeki

Re: bypass spamassassin on ongoing messages

Posted: Fri Feb 12, 2010 9:25 am
by faris
Hi Zeki,

I think we need to go back to the start.

Which spamassassin rules actually trigger when you send email from your server? It may be that the best solution is to look at those rules and either eliminate what's triggering them, or change how much they score, or something along those lines.

The only thing I can think of off-hand would be if the connection comes from an IP that is listed in spamhaus or sorbs or whatever else might be in the header check rules in spamassassin. You can then either reduce those scores, or increase the score nedded to make the message get tagged as spam.

Or, by removing the PTR record completely from the local DNS, which is what we're currently discussing, it might be possible to get a more concrete hostname mentioned in the header which will allow the rule we've been discussing to work. Or maybe not. But that's why we are discussing it.

Faris.

Re: bypass spamassassin on ongoing messages

Posted: Mon Mar 21, 2011 10:00 am
by breun
Yeah, the SpamAssassin rule mentioned above doesn't really work well, because all incoming e-mail will match it...

Does anyone have any experience with the qmailsmtpauth plugin for SpamAssassin? It looks like it does pretty much the same thing, so I'm afraid that's not really a good idea either.

Re: bypass spamassassin on ongoing messages

Posted: Tue Mar 22, 2011 7:36 pm
by breun
My latest idea: add RELAYCLIENT=1 to env in /etc/xinetd.d/submission_psa and service xinetd restart. It looks like qmail-scanner is now correctly identifying e-mails sent via SMTP auth on port 587 (submission) as sent by a relay client (I see RC:1 in the header added by qmail-scanner) and skips scanning for these messages.

I read that 'normally' qmail smtp auth patches set RELAYCLIENT=1 when smtp auth has succeeded, but apparently this mechanism is not present in Plesk's qmail distribution (or it doesn't work somehow). It appears to me that explicitly setting RELAYCLIENT=1 for messages that come in via the submission port is fine though, since submission is only accessible when using smtp auth.

I'll do some more testing. Let me know if you find a flaw in the logic above.

Re: bypass spamassassin on ongoing messages

Posted: Sun Mar 27, 2011 6:19 am
by breun
This all seems to work just fine. I don't like modifying /etc/xinetd.d/submission_psa though, because I'm afraid that Plesk will one day overwrite that file, so I cooked up a patch to qmail-scanner which checks for the SUBMISSION=1 environment variable set by /etc/xinetd.d/submission_psa and then treats these e-mails as sent by a relay client (which is in fact the case) by setting QS_RELAYCLIENT=1. This way these e-mails are not scanned and get 'RC:1' in their header, which indicates an e-mail is sent by a relay client.

The patch is only a one line change:

Code: Select all

# diff -u /usr/share/qmail-scanner/qmail-scanner-queue.template.orig /usr/share/qmail-scanner/qmail-scanner-queue.template
--- /usr/share/qmail-scanner/qmail-scanner-queue.template.orig  2011-03-27 12:06:26.000000000 +0200
+++ /usr/share/qmail-scanner/qmail-scanner-queue.template       2011-03-27 12:03:37.000000000 +0200
@@ -634,6 +634,7 @@
 #it later without changing how Qmail actually interprets
 #RELAYCLIENT
 $QS_RELAYCLIENT=1 if (defined($ENV{'RELAYCLIENT'}));
+$QS_RELAYCLIENT=1 if (defined($ENV{'SUBMISSION'}));
 
 if ($ENV{'TCPREMOTEIP'}) {
   $remote_smtp_ip=$ENV{'TCPREMOTEIP'};
Run qmail-scanner-reconfigure afterwards to apply the modified template.

What do you guys think? Do you see any problems with this patch? Scott, would you apply this patch to the qmail-scanner package in atomic?

Re: bypass spamassassin on ongoing messages

Posted: Sun Mar 27, 2011 11:28 am
by biggles
Sounds like a great idea. What do you think, Scott?

Re: bypass spamassassin on ongoing messages

Posted: Sun Mar 27, 2011 12:16 pm
by scott
You get the Clever Girl award for that patch:

http://shirtshovel.com/products/movies/ ... rl-434.jpg