[Top] [All Lists]

Re: deprecate implicit MX even for IPv4

2008-04-08 08:23:55


This is my 2 pennies:

I agree overall with your passion and experience. As a commercial vendor since the 80s in multiple mail networks, even some that predated SMTP, my customers are wide in needs. When it comes to a particular "issue" whether its a feature, built-in and/or optional, some will want us to solve it for them, others will prefer to deal with it themselves. When there is no major majority, you make it optional.

There are many view points, valid as well. I will say that there is no real justice in trying to express all of the issues, all the view points in such a short period, leaving it to a SWAG - scientific wide-ass guess.

As I said, there is no way to cover all the issues. It really does need to be further researched, documented and consolidated for peer review.

To me, there is a more general philosophical question to get out of the way because it has a direct and indirect relationship to everything we have been doing, including IPv6 ideas:

  In a chaotic world of connectivity, what is the society impact
  to have a low level full duplex, two way communications between
  end points?

  Asked another way, are we going to allow unauthorized
  anonymous senders to continue to prosper?  Does the
  sender require some form of "registration" or contact

I don't know if you realize this there is a long time strategies to connect every peer and server. Many such have Apple, Google, Yahoo, Microsoft with its "Live" strategy are real long term goals where IPv6 will play a major role in creating. Even Apollo and Adobe want a piece of the connectivity action.

Up to this point, the SMTP system has relied on the basic principle that local mail does not require authorization. Only relays.

In the words of Monk, this has been both a blessing and a curse.

A blessing in that it allowed for the spread of connectivity and communications. Without it, I sincerely doubt internet email would be what it is today.

Its a curse in that it open the door for exploitation and abuse.

I think we know that this was not something that just fell through the cracks. As far as 80s, there was many published concerns in the trade of foreseeing abuse with the sender or author domains. In fact, prior to the internet, the public market of dialup online systems did not offer anonymous communications. It required logins, etc.

But yet, even with the new openness, there was also optimistic expectations that this situation came be addressed.

Unfortunately, it never was adequately done, and in my view, it took the an infamous 2001/2002 SORBIG email virus with its unique dual phrase blitz attack on the mail network to finally make the world take notice of the weak provisions in the SMTP mail system and how it has been exploited. Only then did the industry begin in earnest the DOMAIN::IP association and mapping strategies. SPF and SENDERID is a result of that effort.

However, as we all know, these strategies has an inherent flaw with a design presumption that the sender MACHINE is always mapped to the sender DOMAIN in some authorized or permission based manner.

This is directly related the the general question about chaotic connectivity I raised above.

It is also directly related to the idea of identification via A/AAAA records or via a group list we call the MX mail host names list.

Either way, it is still some form of identification.

Also keep in mind there two different philosophies when it comes to implementation of SMTP mail reception and rejection:

  - You have growing SMTP level system that will do SMTP level
    security checking, even now at the DATA state.  These systems
    do 2821 level instant rejections.

  - You have the current majority of SMTP systems with a ACCEPT
    first, check later implementation.  These systems do post SMTP
    accept/bounce rejections - a very troubling part of the Email
    Security problem that continues to threatens delivery

Anyway, there are many intertwining issues to consider including a whole new can of worms with the virtualization methodologies that IPv6 is introducing which to me may even make MX/A/AAAA concepts transparent and obsolete at the application level and may even re-introduce mail hosting routing ideas.

A flat out "MX mandate" or no IMPLICIT MX while it sounds like a good idea as a whole, is it really?


Hector Santos, CTO

Michael Storz wrote:
On Mon, 7 Apr 2008, Robert A. Rosenberg wrote:

At 09:40 +0200 on 04/07/2008, Michael Storz wrote about deprecate
implicit MX even for IPv4:

The longer I follow this discussion and think about it, I am feeling that
the cleanest solution would be to deprecate implicit MX even for IPv4. In
the meantime I am convinced the implizit MX is a defect of RFC 2821. It
was introduced more than 20 years ago as a workaround to get the routing
via explizit MX RRs running.
While I agree with you that the time has come to depreciate implicate
MX for IPv4, I do not think addressing this issue/need should be
commingled with a ban on implicate MX for IPv6. IOW: Ban the
Implicate IPv6 MX as one effort and ban the Implicate IPv4 MX as a
separate effort or a failure of the IPv4 ban may prevent the IPv6 ban
from being effective. I see the 2 bans as SEPARATE issues and thus
should be addresses separately or we will have the IPv4 issue affect
the IPv6 issue. I see the IPv6 issue as something that needs to be
addressed NOW while the IPv4 issue can be fought another day if
needed. We have lived with this problem for 20 years and can live
with it, if needed, for a few more years. The IPv6 issue can NOT be
ignored or we will just end up in the same situation with AAAA record
usage as we have with A record usage. The time to act on AAAA usage
is NOW while the A usage can be addressed later/eventually.

As far as I can see, the discussion is going into the direction of
respecting again the seperation of the different protocol layers as far as
possible (a principle which I do support). And that couples the two
protocols IPv4 and IPv6 closely together. And that means, if you want to
depreciate implicit synthesized MX RRs, you have to depreciate them for
IPv4 at the same time.

Depreciating impicit synthesized MX RRs makes only sense, if you think
that using this feature nowadays with IPv4 or in the future with IPv6 is a
problem. Unfortunately (from my point of view), several people on this
list have expressed that this is not a problem for them.

However, my experience from being responsible (together with my team) for
running email for a large scientific network for more than 20 years, is
different.  For us it is a problem. It would be much better, to have a
clear and clean statement that routing for SMTP is done by MX RRs and
nothing else, basta! and everything else is a configuration error.

But this has never been a design goal. There are several areas in RFC
821/2821 and RFC 822/2822 where such stements are missing (I do not name
them, because I do not want to direct discussion to these points again).

The general design principle has been

- you SHOULD not generate wrong things, but
- you MUST accept them instead of rejecting such messages.

I understand that this attitude was necessary at the beginning to get SMTP
running and having the maximum reachability. But I am absolutely convinced
that this necessity does not exist anymore since a long time.

The result is that more and more ISPs are ignoring the standard. Some of
them have at least the respectability to document this, like Frank just
showed us with the link to the dokumentation of the suppression of DSNs by

Just my 2 cents from the operational world.
Michael Storz


Hector Santos, CTO

<Prev in Thread] Current Thread [Next in Thread>