Topic: One mail recipient domain being blocked?

[bloodshoteye]

Mail to a certain addressees with a particular domain is not reaching it's destination. Here is a brief extract from the header:

Hi. This is the qmail-send program at <ourdomain.co.za>
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<support@telkomsa.net>:
Connected to 196.25.211.70 but connection died. (#4.4.2)
I'm not going to try again; this message has been in the queue too long.
...

Usually this means that the sender (in this case us) has been blocked at the receiving end. So far our ISP has been unable to resolve or shed light on this.

I just want make sure that SME does not do destination filtering on outgoing mail. It will do the usual virus checks, message and attachment size checks and so on.
The server has ClamAV, Spamassasin, additional blacklists and the WBL server panel. This sounds like a lot, but it all relates to incoming mail, not so?

Regards.

[bloodshoteye]

Our ISP has just been in touch - got us to enable smart host capability. This server has been sending directly to the world for years, but now is being blocked by at least one domain.

Tomorrow (it is now 16:40 here) will tell if using the ISP to relay mail will solve this issue.

Cheers,

[janet]

ardugh

If you read the manual fully, you see this
http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Appendix#Appendix_B._DNS
which refers to the need for PTR & SPF when running your own mail server and sending direct to other mail servers. The proliferation of spam and strict spam prevention measures has created the need for all system administrators to be "identity aware" and maintain the credibility of their servers IP to a high standard.
Sending mail via your ISP is a workaround, where the identity of your ISP is then tested. This does not always work well, as on many occasions large ISP's mail servers will also be blocked due to spamming activities coming from a customer account. When this happens, typically dozens, hundreds or thousands of other customer accounts will also temporarily be blocked, and as you are using your ISP via the smarthost setting, then your mail will also be blocked as you are sending mail via one of the blocked (ISP's) servers. These blocks are usually lifted in a day or two or three.

Depending on your needs ie the importance of your mail getting delivered under all scenarios, it may be better to configure PTR & SPF for your domain and send directly, that way you are not subject to the vagaries of service quality that your ISP provides (over which you have little control). If sending direct at least you can control everything, with some initial effort to get the system well setup ie external DNS records etc, which usually need to be done via your ISP and DNS zone record manager. You may also need to join up various large service providers monitoring programs eg hotmail, to have mail sent from your server to hotmail accounts monitored, so you can then have your server IP listed on hotmail "whitelists". It takes some effort to get it all setup but it's worth it in the end, as all your sent mail will get through, as your server is not likely to ever appear on external blocklists.

[bloodshoteye]

Thank you mary for your insight and the pointer to some well written documentation on DNS.

Management here are of course relieved that mail is now flowing out to the previously blocked domain. We were unable to zero in on the exact point of blockage after 4 days of effort. I feel reverting back and continuing that struggle will not receive approval right now.
Of course I can continue to make inroads whilst under the smart host setup, and if successful, send directly later on.

Cheers,

[CharlieBrady]

Usually this means that the sender (in this case us) has been blocked at the receiving end. So far our ISP has been unable to resolve or shed light on this.

Only the admin of the mail server at 196.25.211.70 (mail.telkomsa.net) why their server is disconnecting the connection from your mail server without providing a proper SMTP response.

I just want make sure that SME does not do destination filtering on outgoing mail.

It doesn't, and that is clearly not the problem here anyway.  The problem is "Connected to 196.25.211.70 but connection died".