bypass spamassassin on ongoing messages
Re: bypass spamassassin on ongoing messages
I'm only getting the encrypted part when I use SSL and access the server via port 465
Re: bypass spamassassin on ongoing messages
Hmmm... I see the problem, yes.zeki wrote:That's what I tryed... Then it matches on every incoming mail... with -10 point.....
The hostname is not actually getting in the right place. It is just the PTR on the IP.
Faris.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
-
- Forum Regular
- Posts: 471
- Joined: Mon Dec 06, 2004 10:43 pm
Re: bypass spamassassin on ongoing messages
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.
Any other PTR records for other domains hosted should then be removed, correct?
Thanks.
Re: bypass spamassassin on ongoing messages
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.
(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.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
Re: bypass spamassassin on ongoing messages
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?faris wrote:But only the IP used to send email, which is usually the main or first one, absolutely 100% needs a PTR
Lemonbit Internet Dedicated Server Management
Re: bypass spamassassin on ongoing messages
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.
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.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
Re: bypass spamassassin on ongoing messages
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.
Lemonbit Internet Dedicated Server Management
Re: bypass spamassassin on ongoing messages
I didn't think of that! That would effectively remove the in-arpa record completely, wouldn't it. I think you are right.
Faris.
Faris.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
Re: bypass spamassassin on ongoing messages
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
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
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.
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.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
Re: bypass spamassassin on ongoing messages
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.
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.
Lemonbit Internet Dedicated Server Management
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
Re: bypass spamassassin on ongoing messages
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.
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.
Lemonbit Internet Dedicated Server Management
-
- Long Time Forum Regular
- Posts: 2813
- Joined: Sat Aug 20, 2005 9:30 am
- Location: The Netherlands
Re: bypass spamassassin on ongoing messages
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:
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?
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'};
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?
Lemonbit Internet Dedicated Server Management
Re: bypass spamassassin on ongoing messages
Sounds like a great idea. What do you think, Scott?
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
Re: bypass spamassassin on ongoing messages
You get the Clever Girl award for that patch:
http://shirtshovel.com/products/movies/ ... rl-434.jpg
http://shirtshovel.com/products/movies/ ... rl-434.jpg