ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - RMX I Never send mail

2003-09-26 12:52:45
On Fri, Sep 26, 2003 at 09:26:59PM +0200, Markus Stumpf wrote:
On Fri, Sep 26, 2003 at 12:07:13PM -0700, Dennis Gearon wrote:
this RMX scheme, it guarantees  only that the server sending and email 
can use the name for the server in the FROM field, correct?

Kinda. Only hosts listed with RMX for a domain can send eMails with
Envelope-Sender addresses of that domain.

It doesn't 
guarentee that the username is correct, right? And it is open to relays 
being taken over, right?

Correct in both.
And it breaks forwarding, and I don't like the artificial routing
information they want to put into the addresses to "fix" it. Even if
they use e.g. '#' instead of '%' it will bring all the problems that we
had with the '%' address paths.

I agree with Markus.

But IMHO we need something started rather fast.
I am writing up a draft (which I'll try to finish in a first version
over the weekend).
It has for one a much weaker authetication scheme that all the other
"RMX" like proposals use, but it doesn't need changes to bexisting
Internet techniques and it doesn't break anything existing.

What I propose is to label hosts like
   o  "This IP address is assigned to a MTA that is intended to send
      messages across the Internet"
   o  "This IP address does not host a MTA, do not accept emails from
      that IP address."

This is exactly what we've been wanting for some time now.  In some ways,
we are doing it today.  For example, we whitelist based on some criteria
which gives us a high certainty that the connection is from a real MTA.
And we blacklist dynamic IP addresses and the like which gives us a high
certainty that the connection is from an IP address which does not host an
MTA.  What we need now is to formalize this and distribute the information
in some manner (e.g. DNS).  Allowing IP block owners to set up these
attributes is a key difference from what we have today (DNSbls) which is
pretty centralized and more error-prone.

We cannot depend/trust on all the millions of so called admins out there
to have control over the software on their computer and keep up with
security holes. So why don't we give them an *easy* instrument that
is independant of their software.
If they (or their ISP) can add records like (BIND notation)

    1.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=yes"
                          IN  TXT  
"ASRG.CONTACT=mailto:abuse(_at_)example(_dot_)com"
    2.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=yes"
    *.0.0.10.in-addr.arpa.  IN  TXT  "ASRG.MTA=no"

I agree that we need to use an existing DNS RR to provide this information,
but I also believe that we should define a new RR to be used in preference
to this method for the long-term.  Perhaps an "MTA" RR.  TXT records are too
general-purpose to be used long-term, IMO.

nobody has to care about whether the workstation with IP address
10.0.0.13 is infected by a virus or has an open proxy server. It is
labelled ASRG.MTA=no and no MTA will accept messages from that host
unless the sender has a stronger auth mechanism to override this label.

With this proposal we don't need new records defined in DNS, we don't
need some 10 DNS queries to find out whether a given connection is
allowed to send email with a sender address in domain  example.com  and
we don't have to care about 512 byte DNS packet limitations.

It is a weaker proposal as the other RMX like mechanisms, because it
does not try to match domains to valid MTAs for that domain. But it is
cheap in use and implementation, it is easy implemented, we don't need
new DNS records.

This "weakness" is actually something that will allow more sites (such as
our own) to adopt it.  We could NEVER adopt RMX due to its tying the
originator domain name with the connecting IP address.  That won't fly here.

A "MTAmapd" can run in front of a standard MTA. The MTAmapd accepts
the connection, looks up TXT records for the IP address of the sender
and if it has MTA=no it sets and ENV variable for the "real" MTA.
The "real" MTA can clear this ENV variable if the connector can
authenticate via a stronger auth scheme (e.g. SMTP AUTH). If the
receiving MTA sees a RCPT TO and the ENV var is still set it will
reject the command with a
   550-5.7.1 Message rejected. Sender is not labelled a valid MTA.
   550 5.7.1 Please contact <abuse(_at_)example(_dot_)com>.
and the contact address could be taken from the ASRG.CONTACT record
and be supplied as content of the ENV var.

This is easy, fast, cheap and effective ;-)

There are a number of ways that this could be implemented; given the
amount of open-source software out there, a patch could easily be made.

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