Subject: [Asrg] Reverse MX [RMX] proposal

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Fri, 28 Nov 2003 14:39:30 +0200

Couple of comments after reading Reverse MX proposal, RMX records and MTAMark draft.

There are other proposals too, but they seem to do work
mostly on domain specific configuration where as RMX and
MTAMark concentrate on network specific configuration.

MTAMark draft tells us the problem (from the spam point of view),
and they have done great job, but I think it's a little too complicated
to maintain. It may require configuration per domain if virtual
domains have their own MX setup (this does not apply to all setups).
Also, I don't like parsing TXT records (Parsing == bugs == troubles).
Bind and Tinydns seem to differ in TXT records, too. Some Bind versions
send extra character (space or ") (parser bug?) whereas Tinydns doesn't.
Conclusion: I'm against TXT records. 

RMX records (Do not confuse with Reverse MX records) is domain specific. 
It's simply a list of IP addresses that can send email from some domain.
In reality, some of the users may use just about any sending SMTP 
server [depending on their ISP]. For example,  I have a client that 
operates in couple of countries, each using different ISP, yet the
incoming MTA is always the same, outgoing MTA is never the same.
They could be using SMTPAUTH, but instead they use email server
of ISP to send out messages. Do you think I could do something
about it? Should I administrate a list of outgoing mail servers for my 
client in this case? No. It's not my job, so I'm against it and I believe
most of the administrators are against it. Also, RMX requires new 
record type, that some bind versions refuse to send out.

Reverse MX records tell one thing:
List of SMTP server IP addresses that are trusted to communicate
to outside networks. It's up to the receiving MTA to use that information.
Every administrator can choose whether they utilize that information or not.
Network owner does not block outgoing smtp connections.
RMX is simple to administrate. It's just a list of IP addresses.
It's simply a MX record in reverse zones.

Example:
Network administrator of 1.2.3.* network sets up a list of the 
smtp servers [aka: trusted MTAs] that are supposed to talk 
to outside networks. The list containst: 1.2.3.5 and 1.2.3.6

MTA Administrator at 4.5.6.7 (mailslave.company.dom) -chooses- to add
rmxsmtpd [imaginary software at this point] to his set up. 

User at 1.2.3.10 sends out an email message. Message is first
transmitted to 1.2.3.5 [users outgoing mail server] which 
contacts 4.5.6.7 (MX for company.dom)

MTA at 4.5.6.7 checks for Reverse MX records for the contacting
IP address [3.2.1.in-addr.arpa] and finds a list that containst
1.2.3.5 and 1.2.3.6. The contacting IP address [1.2.3.5] is on the 
list and message is accepted. [Other checks, like RBL may 
ofcourse block the service after that, too]

Scenario 2: 
A virus infected users machine [1.2.3.10] and tries to send email 
using its own smtp server (tries to send email to everybody on the 
users contact list). 

MTA at 4.5.6.7 checks for Reverse MX records, finds a list
and determines that this ip is not trusted. Message is not accepted
for delivery.

Scenario 3:
User at 1.2.3.10 chooses to spam 10 million users (to get sales leads!)
and uses special purpose smtp server on his machine to do the job.

MTA at 4.5.6.7 checks for Reverse MX records, finds a list
and determines that this ip is not trusted. Message is not accepted
for delivery.

Scenario 4:
MTA Administrator at 6.7.8.9 has not (yet) set up the smtp server
to check for Reverse MX.

Messages will be accepted (other passes, like RBL, may deny
the access).

Scenario 5:
MTA Administrator at 4.5.6.7 sets up the reverse mx check,
but network administrator for 1.2.3.* has not yet set up a list
of trusted smtp servers in his network.

User at 1.2.3.10 sends out a message using 1.2.3.5 (his 
outgoing MTA). 

MTA at 4.5.6.7 tries to check for reverse mx but doesn't find
anything. Currently, I think MTA should accept the delivery,
but after 1st of June 2004 (reasonable time to set up the list)
the MTA utilizing reverse mx check may not accept the delivery.
MTA should respond; "Your IP [1.2.3.5] is not listed in Reverse MX! 
Contact your mail or your network administrator. See http://www.reversemx.org/".

Implementing (technology):
Users of qmail can utilize RBLSMTPD to block out open relays etc, 
and after a quick look to the code I think it should be reasonably 
easy to modify code for this purpose (RMXSMTPD)

Implementing (the people):
I think this reverse mx must be made mandatory for all networks.
However, I believe people will be educated by their users better - 
in other words, when the policy change comes (1st of June 2003) 
administrators will get a hell of a lot calls from their users and 
will be forced to set up a list. 

Blocking out evil people (spammers with own network):
It's easy enough to block them out using RBL.

References:

Reverse MX http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx
MTAMark http://www.space.net/~maex/draft-irtf-asrg-mtamark-00.txt
RMX Records http://www.mikerubel.org/computers/rmx_records/

--
Tomi Panula-Ontto, Koodia Ltd.
E-mail: tomi AT panula-ont DOT to

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 28 Nov 2003 09:06:33 -0800

Any news on further work from the LMAP group - a revised LMAP Discussion 
and Applicability Statement? An LMAP design document?
Another suggestion for the Statement: it should go over WHY it does not 
examine or verify the body From: field - which, IIRC, a post to this 
list went over - there's a case or two where it's legitimate for it not 
to match, yes? -e.g. legitimate relaying and forwarding?

The recently re-proposed "rMX and rDNS co-operate" concept is an 
interesting idea, but it fails in several respects where LMAP doesn't, 
beyond those already mentioned.

Verisign patent promoter (P H-B) wrote:

> The other practical problem is that there are machines with several 
> hundred
> thousand email domains parked on one machine. 

It's indeed a problem because of who it puts in charge of maintaining 
the authorized sender info, as I'll get into below.

>Conclusion: I'm against TXT records. 
A bug in the TXT part of software that has known security holes and MUST 
be replaced anyway isn't a deal breaker, IMO; I'm assuming these bugs 
are only in old versions.

>record type, that some bind versions refuse to send out.
Argument built on a false foundation.  Your client isn't using "just 
about any sending SMTP server".  A short list of the IPs of the SMTP 
servers of the two (or 20) ISPs your client uses is 0.0% of the SMTP 
servers on the 'net. 

Expanding on Yakov's and PHB's comments: LMAP's being domain specific 
instead of network specific is a strength not a weakness, because of who 
it puts in charge of creating/maintaining the authorized sender info.  
It puts someone with a vested interest in having that info be accurate 
in charge: the domain owner, who under LMTP is going to tell you that it 
now is your job to administrate a list of outgoing mail servers.  This 
is way better than putting perhaps a large, spammer-friendly ISP, e.g. 
most of the 'Tier 1s' in the US in charge, or the admin of a machine 
hosting thousands of domains, both of whom, assuming they take the 
unlikely step to set up the records at all, will likely do a poor job 
maintaining them, because it's what their spamming customers will want.  
If one of their customers is spamming, you expect them to change the 
record to remove authorization for the spamming IP, but that's roughly 
equivalent to terminating that customer, and we all (should) know, 
they're often not doing that today, so there's no reason to expect 
they'll do it tomorrow. 
Network specific authorization (the "rMX and rDNS co-operate" scheme) 
doesn't prevent domain forgery.  With LMTP, bad lists only hurt the 
domains they are lists for; with network specific authorization, an 
authorized IP can hurt (forge) all domains.

>to outside networks. 
Under the "rMX and rDNS co-operate" scheme, this list is of IPs trusted 
(i.e. listed) by people who have often proven untrustworthy.

>Reverse MX <http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx>
LMAP: 
<http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 28 Nov 2003 13:13:59 -0500

Please take a look also at the LMAP discussion draft:

http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt

Tomi Panula-Ontto wrote:
> Reverse MX 
> http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx 
> <http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx> 
> 

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my 
tongue." (MIT's 404 Message)
-------

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 28 Nov 2003 13:41:47 -0500

> and Applicability Statement? An LMAP design document?

  I'm currently working on updating the discussion paper.

  There isn't a design document.  Instead, I'm working in another
document which compares the technical details of the various
proposals.

> to match, yes? -e.g. legitimate relaying and forwarding?

  Yes.  The document discusses forwarding.  It doesn't discuss
legitimate relaying.

  I find it interesting that in all of the discussions surrounding
RMX-style solutions, I don't recall anyone mentioning off-site MX
secondaries.  So far as the primary MX is concerned, they're
authorized relays.  But the secondary SHOULD also apply as much as
possible the same filtering schemes to the messages, otherwise
spammers can use it as an "open relay" to the primary.

> it puts in charge of creating/maintaining the authorized sender info.  

  Exactly.

  In addition, while spammers can currently use any IP to send spam,
LMAP gives the recipient something *other* than a random IP to blame:
the domain.  So spammers have to do more work to find domains with
permissive LMAP information, and the recipient has one more piece of
information to use in applying content filters.

  It's not about LMAP solving the worlds problems.  It's about a
system of layered defences against spam.  LMAP is just one piece of
the puzzle.

  Alan DeKok.

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Sat, 29 Nov 2003 10:11:22 +0200

----- Original Message ----- 
From: "Matthew Elvey" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 28, 2003 7:06 PM
Subject: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX] proposals

[cut]
> are only in old versions.

It's easy to say "must", but lot harder to get all the servers upgraded.
It isn't deal breaker; MTAMark has very good qualities (and I think I had
a little misunderstanding on my side here about it).

> servers of the two (or 20) ISPs your client uses is 0.0% of the SMTP

Well, I'll give an example: client operates in more than 20 countries, has
travelling salesmen and agents in many countries. Yet, they all use same
email domain and everyone uses their current ISP to send out messages.
Notice: Travelling salesman maybe connecting even from hotel network.
>From my point of view; outgoing MTA can be any server in the world.
How could I know I should temporarily add record for MTA of some
ISP the hotel is using ?

I agree that domain specific configuration would be better, but it's
simply another layer of control. I think we should have network
level control (legitimate MTAs for some network) AND we should
have domain level control. The whole problem of SMTP is that
it has had no control mechanisms at all. Anyway, at this point I think
the network is nearest (and easiest; IMHO) control mechanism
and at this point my interest is on the network centric approach.

When IP addresses get restricted, the spammers will have to use
those servers that are "trusted" and it's lot easier to point the spammer
from a known IP list than from approx. 2^32 IP addresses.
Spammers are a moving target, changing their sending MTA all
the time and I'd like to make them a sitting target. Bad behaving
networks can be blocked out using RBL.

> (i.e. listed) by people who have often proven untrustworthy.

This is true, we will have problems if the network administrators are
untrustworthy. However, if 20% of network administrators are untrustworthy
and 80% are trustworthy then I'll be happy to RBL the untrustworthy
networks away.

> >Reverse MX
<http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=d
ns&doc=reverse_mx>
> >RMX Records http://www.mikerubel.org/computers/rmx_records/
<http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap
-discussion-00.txt>

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Sat, 29 Nov 2003 14:37:06 +0200

Little addition:

Network based control mechanism for MTAs and
domain based control mechanisms can co-exist very
happily.

Network based control mechanism tries to ensure that
the contacting MTA is trusted/registered at that network.
Spammer can register own network, this control mechanism
will fail (but can be detected using RBL).

Domain based control mechanism ensures that the sender
sends the messages from the registered MTA for that domain.
However, any spammer can register tens of domains for them
and send spam using his own MTA which is registered to those
domains.

Neither of the control mechanisms above can verify that
the sender is actually who (s)he claims to be, but when used
together the network based control forces the spammers use
indirect connections (using the MTAs registered for the network
they are using). Domain based control mechanism forces them
to use domains they have registered.

----- Original Message ----- 
From: "Tomi Panula-Ontto" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 29, 2003 10:11 AM
Subject: Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX]
proposals

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Nov 2003 10:56:47 -0500

"Tomi Panula-Ontto" <[email-masked]> wrote:> Well, I'll give an example: client operates in more than 20 countries, has
> email domain and everyone uses their current ISP to send out messages.
...
> How could I know I should temporarily add record for MTA of some

  Please read the LMAP discussion paper.  It addresses this issue.

  I'll turn your question on it's head: why is it the problem of the
recipient to do the work to tell your travelling salesmen from
spammers who are abusing your name?

  My answer is that it's not.  I'll just toss all of the forged
messages into the garbage, and your travelling salesmen will never get
my business.  That's fine by me, as I'd rather work with people who
don't abuse the network.

  As Hadmut said in his rants in the RMX paper: People have to realize
that if they want to stop forgery (for spam), they must stop their own
forgery.

  Alan DeKok.

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Sat, 29 Nov 2003 21:13:02 +0200

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, November 29, 2003 5:56 PM
Subject: Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX]
proposals

> "Tomi Panula-Ontto" <[email-masked]> wrote:> Well, I'll give an
example: client operates in more than 20 countries, has
>   Please read the LMAP discussion paper.  It addresses this issue.

Nice. I'll quote: LMAP discussion paper, page 1.

    'The LMAP protocol falls with the scope of "changes to existing
applications"'

In ideal world, we would throw away SMTP [and bunch of other protocols,
too].
In real world changing all MUAs, MTAs, firewalls, proxies - all software and
hardware built around this crappy protocol - is way too big overhead that it
could happen now. We have the spam problem now.

Anyhow, this shows interesting problem for someone to think about.
How to make Internet capable of changing or upgrading protocols
every now and then?

> that if they want to stop forgery (for spam), they must stop their own

Good point. I agree that forgery is a big problem - but what can
we do about it as long as we have current infrastructure?

Anyway, LMAP seems to suggest major changes to MTA
which will lead to major resistance in adopting organizations. It'll happen,
but it's just a question of when. Quick acceptance of HTTP shows that
big moves can happen quickly, but there has to be benefit with it, too.
[Yeah, getting rid of the spam could be it, but isn't - new system should
have something "new" you can't possibly get using "old" stuff]

We [people] are very good to adopt new things, it's just that we're
very lousy to give up the old things.

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Nov 2003 14:30:06 -0500

> we do about it as long as we have current infrastructure?

  Quite a bit.

> Anyway, LMAP seems to suggest major changes to MTA

  Huh?  Why?  It involves no changes to the sending MTA, and only
minor changes to the receiving MTA.

> which will lead to major resistance in adopting organizations. 

  There's already major resistance to the idea of doing *anything* to
change the way SMTP is implemented or deployed.

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 29 Nov 2003 19:11:25 -0500

> could happen now. We have the spam problem now.

Take a look at 
(http://www.iab.org/documents/drafts/draft-iab-e2e-futures-04.txt).

-------

---

From: Matthew Elvey <[email-masked]>
Date: Sun, 30 Nov 2003 15:50:21 -0800

Alan, thanks for the updates.

>>to match, yes? -e.g. legitimate relaying and forwarding?
And I forgot - of course MAIL FROM: <> needs to be mentioned as a 
special case.

>spammers can use it as an "open relay" to the primary.
At least one of the servers should; the primary could, as it should have 
access to the envelope and source IP too, right?

Something like this is needed:
"Email submitted to a secondary MX for relay to the primary MX MUST 
somehow have the LMAP policy of the domain it claims to be from queried 
and applied." .  If only the secondary receiving the email will  have 
enough information, then this could be said more simply.
Should this be added to one of the LMAP draft documents?

I just thought of another possible problem with LMAP.  If a spammer 
using direct-to-MX spamware sends email to me, from me, (as I'd bet they 
regularly do) it may not be caught by LMAP.
The system (fastmail.fm) for my domain's MX is the system I use to send 
mail too, so I need to put it on my LMAP record.
What are the remedies to this problem?  Some thoughts:
1)Have the systems be different.  For my situation, that could work*; 
fastmail has lots of IPs, so incoming and outgoing can be different, and 
only the outgoing would be in my domain's LMAP record.  For folks with 
one IP, it's a problem. Any ideas?
2)I authenticate and use SSL when I login to the SMTP server to send 
mail. (It requires that I authenticate, and if my password is going over 
the 'net, I require that it be encrypted.) Perhaps the LMAP part of the 
server could be made aware of this, and allow email where from=to only 
when there's authentication.
3)I could stop sending mail to myself, servers could require users not 
do this, and users could be taught that they can't do this.  Requires 
end-user training. (Bad!)

*They are only sometimes different today - it's a mess:  There is 
incoming and outgoing mail at 66.111.4.60=mail.messagingengine.com and
66.111.4.20=smtp.us.messagingengine.com; I think my outgoing mail comes 
from several IPs in 66.111.4.0/24, based on a lookup at senderbase.

---

From: Philip Miller <[email-masked]>
Date: Sun, 30 Nov 2003 18:56:22 -0500

> regularly do) it may not be caught by LMAP.

LMAP is supposed to be checking the IP of the connected client against DNS. 
Unless they can forge a TCP connection with the MTA without seeing any of 
the traffic, they can't pull that off with LMAP going. Now, if they were 
actually fastmail.fm users, that would be another story. In particular, I 
think dealing with that falls under the umbrella of 'local policy'.

Philip Miller