fixing insecure email infrastructure (was: Re: [eweek article]

Wed Jan 26 00:52:53 UTC 2005

On Wed, Jan 26, 2005 at 09:26:04AM +1100, Mark Andrews wrote:
> 	You are adding a prefix not a type.  If you added a type there
> 	would be no issue.  It would work with existing RFC 2317 sytle
> 	delegations.

The issue would be deployment.

  Design Choices When Expanding DNS (draft-iab-dns-choices-00.txt)

While I agree with the proposal in principle that a new RR type would
be the best choice (at least for a lot of situations) there are situations
where
a) deployment is way too slow (even with RFC 3597)
   DNS servers/stub resolvers/caches is one but not the only issue,
   management software is one of the many others
b) it is not usable (just think SRV records and one would need a new
   RR type for every protocol/service)

When we started with MTAMARK we thought about using
    Rosenbaum, R., "Using the Domain Name System To Store Arbitrary
    String Attributes", RFC 1464, May 1993.
and using TXT labels
    "ASRG.MTA=yes"	or "ASRG.MTA=1"
    "ASRG.MTA=no"	or "ASRG.MTA=0"
at the same level as the PTR records.

This is without any problems as related to RFC 2317, however there may be
collisions with other TXT records, if there are other TXT records you
have to wade through them to find if there is one suitable and if there
are others there is always the 512 bytes limit.
Thus we were convinced to switch to a scheme with a precise question
that should also be extensible, as reputation and publishing policies
in the future will be an even more important issue as they are now.

> 	No.  I'm saying that by unnecessarily using a prefix for
> 	MTAMARK it is introducing complications.

We don't think the prefix is unnecessary, quite the contrary.

> 	So you are not going to delegate /24s?  Are you going to remove
> 	the existing /24 that have been delegated?  They fact that customer
> 	needs a /24 doesn't magically make them compentant.  I repeat size
> 	is no indictation of compentance. 

The fact that a customer needs a /24 doesn't automatically imply that
he needs control over the reverse DNS. Our support staff usually
adds/changes records to zones within 30-60 minutes. We monitor every
reverse zone we delegate, if the customer thinks he must have control.
However there is no obligation to do so and if the customer breaks the
zone and is unable to put things straight and keep it that way, we remove
the delegation.

> 	Well for this to be effective you have to own the DNS server.
> 	Then again for really small shops this box will already be the
> 	mail server and will already have a MTAMARK or are you going
> 	to ban your customers from running mail servers on their
> 	bussiness class accounts.

A lot of the problems arise from 0wned broadband hosts. With SPF or
Sender-Id and even DomainKeys spammers can use throwaway domains
like qrve079uyvqweriuq.biz, put the IP addresses of the 0wned broadband
hosts in the records of the domain and voila, the 0wned host is a
legit mailserver for qrve079uyvqweriuq.biz. With short TTLs for that
records they can exchange the "mailservers" fast. They control the
reputation system (i.e. the forward zone).

> 	Nothing will magically stop spam.  One can reduce / channel
> 	/ identify it by applying a number measures.  None of those
> 	measures is 100% effective.

A lot of the methods could be some orders of magnitude more effective
if some admins would take more care. Some of methods don't require anything
more than a bit of thinking. Not breaking RtoL hierarchy of DNS is one
of them. A naming scheme hNNN.mail.example.com instead of mailNNN.example.com
is another (so a easy whitelist *.mail.example.com could be used).
Using 4.3.2.1.dyn.rev.example.com instead of dyn-1-2-3-4.rev.example.com (as
has been pointed out in this thread before) would help a lot. Everyone agrees,
no one acts, nothing changes.
RP (Responsible Person) records are there since RFC 1183. Populate the
DNS and make the work of abuse reporting tools more easy to contact
the right person, instead of having to wade through whois servers with
broken referrals. It even helps ones own abuse desk, as one gets one email
and not 5 or 6 to all kind of addresses the reporting tools think
*could* be right as they found them somewhere, related or not.

MTAMARK gives caring admins one of a few instruments to make their IP
different and to give it a better reputation. If an address provider
refuses to make this possible, one can always complain and raise the
pressure - or get an address provider who cares.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"