[SpamCop.net - protecting the internet through technology]

[SC-Help] Re: rDNS checks and third party SMTP agents

John E. Malmberg wb8tyw at qsl.network
Wed Feb 2 16:54:58 EST 2005


In article <ctq32d$5a0$1 at news.spamcop.net>,
 "Iain" <ipmarketing at spamcop.net> writes:
> I still working on my same Government project and have a new issue to seek
> help about :-)
>
> One proposal is that opted-in mail be despatched via a coordinated
> cross-Governement eMail service. This is raising numerous issues including:
>
> 1. If mail is not sent in the name of the 'real' Government agency then this
> is both a poor user experience and could be confused for phishing mail
> either by the recipient or a mail scanner (I've seen mail where the scanner
> compared the domain quoted in links included in the body of the message with
> the domain of the sender and if they didn't match would insert a large
> 'possible fraud attempt' tag in red into the message at every link!

Should not be a problem if the mail server is configured correctly.  The
domain that the mail server is operating from does not have to match the
domain name that the message is coming from.

As long as the rDNS and DNS entries are correct for the mail server, only
a very badly broken spam filter should ever trip on them.

And such a broken spam filter probably has such a high positive rate that
no one sane takes it seriously.

As long as both the sending from name and the mailserver network name are
domain names that can only be issued to the government, there should be
no suspicion of phishing.

Where things get funny is when some government employee pays taxpayers money to
register a commercial domain instead of using one of the ones reserved
to the governent that they can usually get for "free".  That sets the
stage for being mistaken for phishing no matter what mail server they use.

The other area where real mail can be mistaken for phishing is is where
government/company mailings are sent out on an external provider's mail
service which has an I.P. address that is shared with other mailings,
and so the domain name of the sending mail server as determined by rDNS
is not associated with the claimed government agency or company.

> 2. If the cross-Government service then simply sends mail in the name
> (domain) of the real agency, then (I presume) unless the SMTP server is
> listed in the real agency's DNS the mail send would fail any rDNS check,
> i.e. the server would appear to be sending mail under a domain for which the
> server were not listed. Is this correct?

No.  rDNS checks apply only to the server name, not the domain that the
mail claims to be sent from.

> 3. To ensure rDNS checks worked, would it be necessary for the sending SMTP
> server to have a valid MX record or would the servers IP just need to apear
> in the domain records? The significance of a 'valid MX' is that this would
> be a cross-Government *sending* service and we wouldn't want inbound mail
> going to it should the regular SMTP servers not be available at any tme for
> some unexpected reason

MX records are only required for incoming mail servers not outgoing mail
servers.  That is one of the weaknesses in SMTP e-mail that various discussions
are trying to come up with a solution to.  There currently is no way that
a domain owner can indicate which mail servers are allowed to relay mail
for an I.P. address.  SPF is a proposed solution for that, but it is
incompatible with existing mail forwarding services.

MX records control what mail server(s) will accept e-mail for a domain name,
and the lack of an MX record for a sending mail server should not cause
any problem unless the spam filter is badly broken as stated above.

As near as I can determine, my broadband ISP has about 12 incoming mail
servers, and an unknown amount of outgoing mail servers, and it does not
look like the the incoming mail servers are used for normal outgoing mail.

> I'm sure Mike is going to read this and think "third party sending
> agency...sounds like a dirty list", but it's not :-) Just well intentioned
> ideas for shared infrastructure which continues to give us issues. The is a
> lot of political desire - 'political' with a big 'P', not company
> politics! - for shared infrastructure with little understanding of the
> technical and imlpementation issues this often raises. The belief is it
> makes things simpler, easier and cheaper, although IMHO it's usually the
> opposite!

I would strongly recommend getting a local person that understands all
the technical issues involved with operating a mail server for multiple shared
domains.

What you want to do is really quite a common and normal thing, so if
the technical staff for the network and mail server know what you want to
do, they should have no problems doing it.  If they can not do it easily,
it means you need to find some that do, or your likely to have a lot of
easily avoided problems.

> Thanks for any help on this. If you can see other holes a shared service
> like this might lead us into please feel free to say (like another user of
> the shared service abusing mail/spam policies and causing the entire service
> to become blocklisted??)

For disaster tolerance, you should have a backup sending server, and such
depending on how critical your need is.

It is pretty easy to set up a mailer that never gets caught by properly
implemented anti-spam defenses.

It is impossible to set up a mailer that never gets caught by some person's
broken spam filter implementation, so it is a waste of time trying to
anticipate more than the elementary things, like never sending HTML or
attachments with out permission.

-John
wb8tyw at qsl.network
Personal Opinion Only


More information about the SpamCop-Help mailing list