MoonPoint Support Logo


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals

Advanced Search
Sun Mon Tue Wed Thu Fri Sat

Mon, Aug 30, 2004 8:38 pm

Blosxom Calendar Plugin

A plugin to add a calendar to a Blosxom blog is available from Mt. Molelog or from here.

When I first installed the plugin, I received an "Error 500" error from my blog's webpage with the error message "Premature end of script headers: blosxom.cgi". The webpage loaded correctly once I changed the ownership of the state directory, which lies beneath the plugins directory. I used the following commands to change the user and group for the directory:

chown apache state
chgrp apache state

I used apache as the owner and group, since my web server runs Apache webserver software. I could also have used chmod 777 to make the directory world writable, but that would be much less secure, since anyone else on the system could then have write access to the directory.

[/network/web/blogging/blosxom] permanent link

Mon, Aug 30, 2004 5:36 pm

No PTR Record

If you receive bounced messages with "cannot resolve PTR record" or "(reason: 554 5.7.1 The server sending your mail [] does not have a reverse DNS entry. Connection Rejected" as the reason listed for the message bouncing, with "" representing the IP address for your SMTP server, or see messages, such as "Relaying temporarily denied. Cannot resolve PTR record for" followed by your mail server's IP address in your /var/log/maillog file, then the email server that received the message checked the Internet Protocol (IP) address for the sending server. It then tried to do a "reverse lookup" on the IP address to obtain the name of the server. If it couldn't perform the reverse lookup, then it would bounce the message with a statement that it couln't resolve the PTR record. A PTR record is an entry in a Domain Name System (DNS) server that maps IP addresses back to names.

If you see references to for messages destined for or users, it is due to the same issue. is owned by AOL

An email server adminsitrator may configure an email server to perform such a check to block spammers. I suppose the thinking is that systems used by spammers are more likely not to have PTR records in a DNS server. But, since many email servers not used by spammers will also not have PTR records, I believe such a check is likely to block as much, if not more, legitimate email than spam. And it is hardly an effective means of eliminating spam, since many systems transmitting spam will have PTR records.

A small business may have its own email server with a domain name that maps to an IP address, but the company's ISP may not have an entry in a DNS server that maps that IP address to a name. In such a case, the business may find that email to some domains bounces with the error message about the missing PTR record.

If you are a system administrator with users reporting that they are receiving bounced messages with the "cannot resolve PTR record" for messages addressed to certain domains, then you can configure your email server to send email to just those domains through another email server instead. For instance, your ISP may have restrictions that prevent you from sending email to more than a limited number of recipients at one time. You may have a mailing list that has more email addresses than the ISP allows to be reachable with one message. So you need to use your own email server to reach all of the members of the mailing list. But some of the mailing list members may be using email servers that attempt to look up a name from the IP address of the sending server contacting them.

If you are running sendmail to transmit email, you can edit mailertable, which will be in /etc/mail on a RedHat Linux system. The mailertable file contains special treatment information for a specific domain or family of domains.

As an example, suppose email to is bouncing with the message about "cannot resolve PTR record". You can add the following line to /etc/mail/mailertable:                   smtp:[]

Once you've added the line, you need to run makemap, to produce the mailertable database sendmail uses. You then need to restart sendmail.

makemap hash /etc/mail/mailertable </etc/mail/mailertable
/etc/init.d/sendmail restart

The first command above will produce or update the file /etc/mail/mailertable.db. I am presuming that you already have mailertable support within sendmail. You can check if that is the case by looking for mailertable within your file as below:

grep mailertable /etc/mail/

You should see something like the following, if sendmail is already configured for mailertable support.

FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl

The above example presumes that the ISP server,, does not require authentication. If the server requires authentication, then you will need to modify the access file, which you may find in /etc/mail. Let's say that the smtp.centrivity server accepts plaintext authentication with a userid of jsmith and a password of GrassHopper. You could enter the following line in /etc/mail/access to have sendmail on your system send the necessary authentication information to the server. "U:jsmith" "P:GrassHopper" "M:PLAIN"

You would then also need to produce or update /etc/mail/access.db using the makemap command.

makemap hash /etc/mail/access </etc/mail/access

In the case of the ISP's server requiring authentication in order to send email through it to a destination address that is not an email addres on the ISP's servers, you would edit the mailertable and access files before restarting sendmail with /etc/init.d sendmail restart.


  1. Using 'mailertable' in Sendmail
  2. SBC-Yahoo ® Authenticated SMTP

[/network/email/sendmail] permanent link

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo