[nSLUG] Sendmail configuration
ian at slu.ms
Wed Mar 19 23:30:42 ADT 2008
On Wed, Mar 19, 2008 at 09:54:20PM -0300, Jon Watson wrote:
> I suspect that this is going to cause you the most grief. While there are
> a ton of spam checks that various hosts use to check incoming email, two of
> the more common are sender callouts and rDNS domain verification.
> When sender callouts are enabled on a mail server, the process is something
> like this:
> 1. Sending mail server connects and says it has email for some local user
> and it is from foo at bar.com
> 2. Receiving mail server stalls the receipt, opens up a new socket, connects
> to the MX server for bar.com and says it has mail for foo.
> 3. If bar.com says that is does indeed have a foo user account and asks for
> the email, the server disconnects and accepts the original email
Nitpicking, in a lot of cases it's just sending and receiving mail
servers, and the receiving one does the recipient verification all in
> A second common check involves verifying the bar.com in different ways. It
> typically involves a reverse DNS lookup in that the receiving mail server
> checks to see if the ip of bar.com matches the IP of the server that has
> connected to it. I think there are generally also different checks involving
> SPF records which can 'authorize' another various other servers to deliver
> mail for bar.com. Some domain verifications only check to see if
> bar.comexists and don't concern themselves with what server is
> connected to them.
Mercifully most people don't actually do the check you suggested at
the start of that paragraph, otherwise it would break when I sent this
email (address is slu.ms, sending mailserver is calvin.axolotl.ca.)
What's more common is checking the HELO/EHLO hostname against the
rDNS, and checking to make sure the From address is sane (ie, not
You will occasionally get other (broken) checks like people who check
to see if the sending mail server is an MX for the sender's domain,
which isn't necessarily true.
> In any case, though, the assumption is that there is some sort of domain
> name involved and if you're attempting to deliver mail from a server that
> has no DNS records, then that is likely where the problem lies. There's
> nothing technically wrong with sending email from a server with no name, but
> over the years that sort of behaviour has been linked to spammers and will
> undoubtedly trigger a lot of alarms on receiving servers.
Piling on here, sending mail from a host with no records *will* cause
you a lot of problems. Sending mail from a host that has rDNS that
looks like either a dialup or generic mass-hosting hostname
(220.127.116.11.masshost.com, host-234.masshost.com etc.) will also cause you
a lot of problems.
If that's not a problem you can solve, sending mail from it directly
is probably a bad idea. Either relay mail through your ISP's
mailservers, or setup a mailserver somewhere else and send through
I'm pretty sure his problem is mainly that he didn't properly specify
a From address, so Sendmail is just filling in
$process_owners_username@$hostname as the from address... and since
Sendmail isn't setup properly, it's using localhost.localdomain.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the nSLUG