Michael,
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
address?
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
reliability.
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?
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
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
Dyndns.
Just my 2 cents from the operational world.
Michael Storz
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com