LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   postfix mailserver (sometimes) blocked (https://www.linuxquestions.org/questions/linux-server-73/postfix-mailserver-sometimes-blocked-773186/)

Kropotkin 12-03-2009 07:34 AM

postfix mailserver (sometimes) blocked
 
Hi all,

I run a postfix mailserver under FreeBSD on a small SoHo server/gateway under my own domain name.

Last week I switched ISPs. For my new fixed IP number, one of the first things I did was request rDNS pointing to my domain. Done.

However, over the past few days, I've encountered three mailservers which bounce my outoing message back:

Code:

Diagnostic-Code: smtp; 554 5.7.1 Rejected
Code:

550 Administrative prohibition (in reply to RCPT TO command)
Code:

Recipient not authorized, your IP has been found on a block list (in reply
    to RCPT TO command)

In the past, with a different ISP, different IP number, I've occassionally seen this happen, but then it was for a specific reason, which was reported, ie, that my IP number was on the MAPS DUL list (dynamic IPs).

The error messages above are kind of vague. :(

I ran my IP number through a database check: http://www.dnsbl.info/dnsbl-database-check.php, but it came up clean.

I am wondering if I am missing some obscure Postfix setting or something... but I have a fairly standard installation and I have no problems with the bulk of my outgoing mail traffic.

Any ideas?

Thanks

Berhanie 12-03-2009 09:56 AM

Quote:

The error messages above are kind of vague.
Yes, it's vague, and according to RFC 1893 the error translates to
Code:

      X.7.1  Delivery not authorized, message refused

          The sender is not authorized to send to the destination.
          This can be the result of per-host or per-recipient
          filtering.  This memo does not discuss the merits of any
          such filtering, but provides a mechanism to report such.
          This is useful only as a permanent error.

This probably indicates that it's not caused by something internal to your mail server. Better check with the recipient's mail admin to see what the problem is.

Kropotkin 12-04-2009 10:48 AM

Quote:

Originally Posted by Berhanie (Post 3778501)
Better check with the recipient's mail admin to see what the problem is.

Should an email to postmaster@[domain that is bouncing me] reach the right person? I seem to recall a 'postmaster' recipient is required for every mail domain, but is that also true in practice?

Thanks.

Berhanie 12-04-2009 03:16 PM

Nothing is absolute in practice, but it should work. You might also check the error msg / mail logs for a URL containing contact instructions, or the whois database for a technical contact.

Kropotkin 12-06-2009 07:02 AM

Well, that was an interesting experiment. I decided to tackle the first two.

#1: checked the whois record, found the name of the technical contact and corresponding email address, postmaster@.. Mailed error message. That bounced, so I Googled the name and found another email address for the technical contact. That bounced as well.

#2: web host is not mail host, so I looked up whois record for mail host, found the name of the technical contact and corresponding email address, also postmaster@.. Mailed error message. My message was forwarded to another account, and it also bounced.

Score: 0/2

It is by no means a representative sample :), but if I may nonetheless be permitted a simple generalisation, it would seem that some organisations are not very diligent about keeping their domain records up-to-date. In both these cases, the original technical contact no longer appears to be with the organisation.

Just to satisfy my curiosity, rfc 2821 does require a postmaster mailbox:

Quote:

Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case-insensitive local name.


Read more: http://www.faqs.org/rfcs/rfc2821.html#ixzz0YudtRJVj
Anyway, now I have to mail the respective end users (the people I am trying to mail), via a relay server; I don't like bothering non-techies with this stuff.

This whole business reminds me why I don't like blacklists. They are too rigid and non-transparent. They stifle communication, which is really the soul of the Internet.

I use greylisting for incoming mail on my smtp server, and that works brilliantly. Most spambots don't retry. Those that get greytrapped, only get blocked for 24-hours. Between that and Thunderbird's Bayesian filter, very little spam makes it to my inbox, and I get very, very few false positives.

Berhanie 12-06-2009 08:29 AM

Bummer. If the receiving domain has a website, it may be worth checking there for contact info.

Quote:

#1: checked the whois record, found the name of the technical contact and corresponding email address, postmaster@.. Mailed error message. That bounced, so I Googled the name and found another email address for the technical contact. That bounced as well.
I suppose you've scanned the bounced mail and logs for alternative contact information.
One last thing you can try with 'postmaster' is telnetting to the MX and manually submitting mail to the bare postmaster address:
Code:

RCPT TO:<postmaster>
. With postfix, for example, you have to manually enable receiving mail for postmaster@domain, whereas, by default, mail to the bare postmaster address is accepted.

Kropotkin 01-22-2010 01:08 PM

update: SOLVED
 
I finally found out which list was blocking my IP: it was the SORBS Dynamic User and Host List (DUHL). This is a list of IP ranges which have been determined to be allocated dynamically, hence, apparently, prone to misuse, presumably by bot networks. It would seem that the IP range in which my IP number falls was once allocated dynamically (this is obviously no longer the case).

One of the mailserver error messages that got bounced back at me indicated this.

For some reason, the DNSBL database check I mentioned above didn't include this, perhaps because it is not a true spam blacklist.

It was easy enough to fix. There is a kind of (semi-)automated system for requesting delisting from that list on the SORBS site, which requires that you have a correct rDNS entry, which I did. It took about four days, but my IP is now delisted. This is something my ISP should be on top of, but that is another matter.

So, it appears that there are various mailserver configurations which use the SORBS DUHL. Most just block you with a generic error message, but some at least say why.

Here is my humble wish: If people configure their mailservers to use a list like this, make sure that, when a message gets bounced, the error message explicitly indicates the reason.

I don't use any blacklists on my mailserver. I find greylisting catches most spam, and Thunderbird's bayesian filters catch almost all the rest. Actually, that is not 100% true: I also block all IPs in China and South Korea. OK, I am not perfect either.... ;)

chort 01-22-2010 02:06 PM

Heh, this is why SORBS sucks. If you search for it on the web you'll find no end of grievances. The list is maintained by a well-known anti-social jerk with very antagonistic views. There are many freely-available DNSBLs that are much higher quality than SORBS. Any time you run into a site using SORBS, recommend that they do a web search and use something better instead.

Kropotkin 01-24-2010 04:18 PM

A Google search did indeed turn up some controversies surrounding SORBS.

To be fair though, the delisting procedure for the dynamic host list (DUHL) is fairly straightforward and reasonably quick.

Also, my main complaint is not so much with the list itself as with the implementations in spam traps which don't indicate on the basis of which list a mail is being bounced. As I mentioned above, some mail systems properly indicate this, with an URL to the list's host, but many just return a generic error message.


All times are GMT -5. The time now is 11:43 AM.