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
No PTR Record
If you receive bounced messages with "cannot resolve PTR record"
or "(reason: 554 5.7.1 The server sending your mail [xxx.xxx.xxx.xxx] does not
have a reverse DNS entry. Connection Rejected" as
the reason listed for the message bouncing, with "xxx.xxx.xxx.xxx"
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
http://postmaster.info.aol.com/errors/421dnsnr.html for messages
destined for aol.com or netscape.net users, it is due to the same
issue. Netscape.net 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 bob.bobaroo@us.danzas.com is
bouncing with the message about "cannot resolve PTR record".
You can add the following line to /etc/mail/mailertable:
us.danzas.com smtp:[smtp.centrivity.net]
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 sendmail.mc file as below:
grep mailertable /etc/mail/sendmail.mc
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, smtp.centrivity.net,
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 smtp.centrivity.net server.
AuthInfo:smtp.centrivity.net "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.
References
- Using 'mailertable' in
Sendmail
-
SBC-Yahoo ® Authenticated SMTP
[/network/email/sendmail]
permanent link
