Strange mail behaviour - various rejection

[coolemail]

THANK YOU Biggles,

I removed

Code: Select all

/var/qmail/bin/greylist

and have got all services working again with

Code: Select all

[root@plesk2 ~]# /etc/init.d/xinetd restart
Stopping xinetd:                                           [  OK  ]
Starting xinetd:                                           [  OK  ]
[root@plesk2 ~]# /etc/init.d/qmail start
Starting qmail:                                            [  OK  ]
[root@plesk2 ~]# /etc/init.d/courier-imap restart
Stopping Courier-IMAP server:
   Stopping imap                                           [  OK  ]
   Stopping imap-ssl                                       [  OK  ]
   Stopping pop3                                           [  OK  ]
   Stopping pop3-ssl                                       [  OK  ]

Starting Courier-IMAP server:
   Starting imapd                                          [  OK  ]
   Starting imap-ssl                                       [  OK  ]
   Starting pop3                                           [  OK  ]
   Starting pop3-ssl                                       [  OK  ]

[root@plesk2 ~]# 

Now just need to re-install spamdyke!

[coolemail]

Well, things appear to be working.

I installed spamdyke, made minor amendments to the config file, and then:

Code: Select all

/etc/init.d/xinetd restart
/etc/init.d/qmail start
/etc/init.d/courier-imap restart

and mails are coming in and out OK.

But the Plesk CP shows that Qmail is not working. Is that normal?

[Kalimari]

Never managed to get Spamdyke running without it showing as not running in Plesk CP. I've seen several other forum posts report the same (atomic, Parallels and elsewhere).

[coolemail]

I have some domains which appear to skip going through Spamdyke mail checking. Most of these are domains who have a server in their office (something like Microsoft Exchange Server) which is hosting their emails.

I would like to get their emails checked for Spam and viruses BEFORE they are sent to the MX record destination.

Domains which are failing have MX records to mail.domain.com and an A record for mail.domain.com > IP_of_Microsoft_Exchange_Server.

I have one domain which IS being checked, and this has no A record for mail.domain2.com and it has an MX record going straight to an external domain.

Can anyone suggest what I can do to get a domain being "washed" before emails are sent on where the email addresses are not being hosted on my server.

Thanks as ever in advance.

[faris]

Hmmmm...

This is relatively easy.

1) Make the MX record for the domain point to your server.
2) Qmail needs to know that it should accept email for the domain in question. This involves adding the domain to the file /var/qmail/control/morercpthosts
3) At this point your system will receive email for the domain and scan it. But now it needs to know what to do with it. So....
4) Add a line similar to domain.com:IP_of_Microsoft_Exchange_Server to a file called /var/qmail/control/smtproutes ---this tells qmail to forward any email it receives for domain.com to the IP in question (you can also use domain.com:otherdomain.com if you have a suitable A record set up somewhere. Indeed it is better to set up an A record because then you can change destination IPs quickly.
5) service qmail restart

And that's about it! However, when you add a morercpthosts file, some people recommend that you tell qmail to rebuild its databases. I'm afraid I have temporarily forgotten what the command is to do that (EDIT: The command is: qmail-newmrh ----thanks to Breun for the reminder). Also please note that the filename morercpthosts and smtproutes are from memory and may actually be slightly different.

Faris.

[faris]

I should add that step 2 is only necessary if the domain isn't already in /var/qmail/control/rcpthosts

If your server is hosting the website but not the email for the domain then normally you sould have turned email OFF for the domain and therefore there would not be an entry in rcpthosts

Faris.

[breun]

And that's about it! However, when you add a morercpthosts file, some people recommend that you tell qmail to rebuild its databases. I'm afraid I have temporarily forgotten what the command is to do that.

Code: Select all

qmail-newmrh

[faris]

Thanks Breun!

[coolemail]

THANK YOU BOTH: faris and Breun. Do please forgive me for not posting this thanks earlier. I need to wait for an agreed time before putting these steps in place and carrying out some remote tests.

[coolemail]

I have a couple of examples with slight anomalies, and I wondered if you might be able to help me sort them.

Example 1 - domain1.com. Currently spamdyke is not checking this domain for Spam.
MX record points to mail.domain1.com, with appropriate A record to their Exchange Server.
Mail is turned OFF in Plesk. Therefore, no entry in rcpthosts
I would like to check this domain for Spam, so:
create /var/qmail/control/morercpthosts and add the domain to that file
/var/qmail/control/smtproutes and add a line domain1.com:mail.domain1.com (faris, is that what you mean by "you can also use domain.com:otherdomain.com if you have a suitable A record set up somewhere" because we do have mail.domain1.com there already).
qmail-newmrh
service qmail restart

Is that right for domain1.com?

Example 2 - domain2.com. I like what it does, but do not understand it! spamdyke checks this and rejects LOADS.
MX record points to external address clusterc.third_party_domain.com
Mail is turned OFF in Plesk. Therefore, no entry in rcpthosts
I currently do not have /var/qmail/control/morercpthosts

so why is spamdyke checking that? I'm delighted it is, and this is the "model" I want to apply to others.

Example 3 - domain3.com. Same setup to domain2.com, but spamdyke is not checking it for some reason (so clearly not the same setup, and I'm not sure what might be different!):
MX record points to external address clusterc.third_party_domain.com
Mail is turned OFF in Plesk. Therefore, no entry in rcpthosts

Could someone help me by confirming with Example 1 that that is what I need to do, and trying to find out why examples 2 and 3 behave differently, getting spamdyke to wash them both?

Many thanks in advance.

[faris]

/var/qmail/control/smtproutes and add a line domain1.com:mail.domain1.com (faris, is that what you mean by "you can also use domain.com:otherdomain.com if you have a suitable A record set up somewhere" because we do have mail.domain1.com there already).

No, not quite right.

Basically the format is DOMAIN:DESTINATION where DESTINATION can be either an IP address or a domain name. If it is a domain name then qmail will do a DNS lookup for the A record of that domain
and forward email there.

So in this case you'd want domain1.com:IP-of-exchange-server

What I meant about using a domain with an A record was more like adding a A record like exchange.domain1.com -> A record -> ip of exhange server.

Then you'd have domain.com:exchange.domain1.com in smtproutes

Then when/if that IP changes, all you do is change the DNS rather than fiddling with qmail control files and restarting all sorts of services.

The MX setup, incidentally, should be that the MX record points to your plesk server and not the exchange server. Please check that.

If you wanted, you could then add a lower priority MX record pointing directly at the IP of the exchange server. So if your server goes down for any reason, yuur client continued to receive email.

HOWEVER, spammers love to use the lower priority MX in order to bypass spam filters. And that's what would happen here. So add a third MX with even lower priority, again pointing to your Plesk server.

There are also a few organisations who offer a low priority MX that you can use. I'm afraid I can't remember who right now, but it was discussed in the spamassassin mailing list and I think it has something to do with hostkarma. Not sure. I really can't remember.

EDIT: SORRY! If mail.domain1.com was the IP of the exchange server then please ignore me and you were right. I just assumed it was for your plesk server but realised I'm probably wrong. Sorry again.

[faris]

Example 2 - domain2.com. I like what it does, but do not understand it! spamdyke checks this and rejects LOADS.
MX record points to external address clusterc.third_party_domain.com
Mail is turned OFF in Plesk. Therefore, no entry in rcpthosts
I currently do not have /var/qmail/control/morercpthosts

so why is spamdyke checking that? I'm delighted it is, and this is the "model" I want to apply to others.

I'm worried that you don't have a morercpthosts

For example1, email should be switched off for domain1, and it should therefore not be listed in rcpthosts (I think?? Someone confirm this please?). It MUST therefore be in morercpthosts in order for qmail to accept any email that passes the spamdyke filters.

But as to your question....

What's probably (just a guess) happening is that the spammers are sending email to the A record of the domain, or they have stored the IP you used to use (which may have pointed to your plesk server?). This happens a lot.

Even legitimate mail senders sometimes send email to the A record of the domain for no apparent reason. It indicates a broken mailer on their side, I think. But I'm seeing it from big companies.


And that takes us to example3....

Maybe a different set of spammers is spamming example2 compared to 3. Maybe it is a newer domain? And therefore maybe they don't have a cached MX or whatever. Just guessing again.

Faris.

[coolemail]

faris,

Thank you for your really helpful replies.
I definitely don't have /var/qmail/control/morercpthosts. I have copied what I have in case that shows where domains would be listed whose emails I am not hosting.

Code: Select all

[root@plesk2 ~]# ls /var/qmail/control
badmailfrom     databytes        dhparam1024.pem  locals  rcpthosts       rsa512.pem      smtpplugins  spfguess  virtualdomains
clientcert.pem  defaultdelivery  dhparam512.pem   me      rejectnonexist  servercert.pem  spfbehavior  spfrules
[root@plesk2 ~]# 

What's probably (just a guess) happening is that the spammers are sending email to the A record of the domain,

I guess this MUST be the case. Example 3 is a newer domain, and yours is the only rational explanation why domain2 is checked by spamdyke and domain3 is not. And the Spammers are VERY prolific on Example 2!!!

If mail.domain1.com was the IP of the exchange server then please ignore me and you were right

That is the case, in which case I will then do the setup we mentioned with mail.domain1.com -> A record -> ip of exhange server (which has the reverse DNS on it also). And I will take your advice and put the other MX records with mine as the lowest priority one. Why do Spammers bother? Nobody likes them!

THANK YOU, as ever, for your help

[faris]

OK, that's all good.

Basically, qmail looks in rcpthosts and then in morercpthosts to decide if it should accept an email or not. If the domain is not in either of those files, qmail will assume the sender is trying to relay, and will therefore say ".... not in my list of rcpthosts" to the sender in a bounce message (unless the sender is an email proggie and authenticates before trying to send, but that's not the case here - we are talking about email coming in rather than email being sent out).

rcpthosts is controlled by Plesk, and when you turn mail off for a domain it gets removed from rcpthosts.

You can add it back in manually, but that's not a good idea as it could easily get zapped again if Plesk re-creates the file at any time.

This is why you need to create morercpthosts manually and add the domain you want to process email for to it, then run that little utility that Breun mentioned somewhere in one of these posts.

If you don't, no email will get delivered to these external domains.

Plesk doesn't touch morercpthosts so it is "safe" to manually edit.

Faris.

[breun]

This is why you need to create morercpthosts manually and add the domain you want to process email for to it, then run that little utility that Breun mentioned somewhere in one of these posts.

You don't necessarily need to run qmail-newmrh, but that command creates a binary version (morercpthosts.cdb) of morercpthosts which makes the lookups quicker. It might not make a big difference if you only have a handful of entries in morercpthosts. But yeah, there is no harm in running qmail-newmrh and having the binary version.

http://www.qmail.org/man/man8/qmail-newmrh.html