[Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX] proposals

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.
On 11/28/2003 4:39 AM, Tomi Panula-Ontto sent forth electrons to convey:

> 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. 
>  
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.
> 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.
>  
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.
> Reverse MX records tell one thing:
> List of SMTP server IP addresses that are trusted to communicate
> 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>
> MTAMark http://www.space.net/~maex/draft-irtf-asrg-mtamark-00.txt
> RMX Records http://www.mikerubel.org/computers/rmx_records/
>  
LMAP: 
<http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap-discussion-00.txt>


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg