Email Server and DNS

Sun Nov 3 18:00:23 UTC 2013

On Sun, Nov 3, 2013 at 11:08 AM, Rich Kulawiec <rsk at gsp.org> wrote:

> non-generic DNS/rDNS.  ("non-generic" meaning something that looks
> like a host that should sending and receiving email.  In other
> words, mailgw.example.net looks real.  ip-137-12-16-164.example.com
> looks like a random host that's probably part of a botnet.)
>

This is a good idea, but you can use a generic hostname if you want.  It's
not a consensus that you need a non-generic hostname.

There can be negative consequences for mail delivered to some recipients,
because SpamAssassin and some other reasonably popular spamfilters, will
use a regular expression based on a sending mail server's rDNS name to
decide that "ip-137-12-16-14.example.com" is not a bonafide mail server,
based on the hostname alone;   this can increase the probability that
legitimate mail you send will be miscategorized as spam,  if  you do choose
to use a generic hostname for a mail server.

http://svn.apache.org/repos/asf/spamassassin/branches/jm_bug_3852_two_level_configs/rules/20_dynrdns.cf

There are many ad-hoc rules  that spam filters will  subject messages and
sending mail servers to, that are not part of the formal requirements for
sending MTAs.

Make sure that you HELO/EHLO as the same host -- unless there's
> some good reason not to.  There probably isn't.
>

The RFC contains a MUST NOT  in regards to verifying the  HELO name matches.
So, the HELO can use any hostname ---  as long as the hostname forward
resolves to something;  it should resolve to the IP address of one of your
mail servers.    Some mail servers provide service for many domains, and
have many DNS names that could be placed in a HELO.

The general rule here is:   Look at what is common, what is the simplest
and most likely  way for mail server operators to present themselves.

You don't want your mail server to look any different  to the outside
world, either in operation, naming, or forward and reverse DNS
configuration, HELO messages, etc,  from a majority of other legitimate
mail servers.

> SPF is worthless crap: don't bother.  Use a real MTA, e.g., postfix
>

I do not believe that is the consensus of the community -- or the working
groups behind the SPF-related RFCs.   There are many mail servers and spam
filters that will enforce SPF policies;  there are also a number that will
synthesize an "implicit"  policy  of  Soft (or hard) Fail  for any sending
IP, except the MX or base A name IP, if you do not publish  explicit SPF
records.

I have a spam filter that penalizes messages from domains with no SPF
published, or not matching a high-granularity allow condition by scoring
them as more likely to be spam;  greylisting may be caused by a soft fail,
 and of course, messages will be rejected on a hard fail.

If you are serious about running an outgoing mail server;  I do not believe
you have the luxury of completely ignoring SPF,  DKIM / domainkeys /
sender-id, and other established or emerging community standards.

After all, they can be used as a tool to help reject some spam.
e.g.  spoofed  @usps.com messages

> Don't use a quarantine, it's a horrible idea.  (Ask RSA how that worked
>

Message quarantines are great;  they are helpful  for mitigating the false
positives of overly-agressive filters.
A combination of  quarantine and reject policies can be useful,  for border
cases.

Especially, if there are some users that "want"  spammy messages,  which
are actually HTML bulk-sent newsletters of some sort or another.

out for them.)  Make sure you don't backscatter.  Make sure you don't
> use SMTP "callouts", which are just as abusive as spam.  Make sure you
>

Implemented appropriately;  an SMTP callout (or "SMTP connect"
verification) to the connecting IP is a great way to help resolve the
suspiciousness level of the sending mail server.

SMTP connect verification is a good thing to be using,  when the sending
server is using an  envelope From domain, that has not yet bothered to
publish the proper SPF records  to verify them.

There are bad broken SMTP callout implementations that should be avoided,
and there are rather useful ones.

> have working "postmaster" and "abuse" addresses.  Make sure your MTA
> doesn't emit or respond to return-receipts.  Read your logs (again).
>

Of course, read receipt requests should be suppressed when dealing with
internet hosts.
Having a working postmaster address is a requirement.

Using the name abuse@  for the abuse contact  is not required,  and it is
likely to be targetted by spammers.

Working abuse and technical contacts should be published  in the IP address
and domain name WHOIS databases for  the mail server's  primary domain,
 and all envelope from domains  that  can be originated on that mail server.

---rsk
>
--
-JH