I'm only getting the encrypted part when I use SSL and access the server via port 465

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.

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.

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.

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?

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.

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.

I didn't think of that! That would effectively remove the in-arpa record completely, wouldn't it. I think you are right.

Faris.

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

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.

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.

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.

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?

Sounds like a great idea. What do you think, Scott?

You get the Clever Girl award for that patch:

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