Due to heavy work load I hadn't been able to follow the list in a
timely fashion. During the last two days I tried to catch up with the
emails and drafts and more than one time I was close to ROTFL reading
about where this group went to.
There is and was so much talk about deployment and sizes (of DNS
packets) before in ASRG and also here on this list and now look
where it ended up? We put KBs of XML language in DNS TXT records.
There are includes and stuff ... did you even think about what kind
of DNS storms large mailservers will kick off during prime time?
Oh and we will all need new mailservers to afford all the CPU power
necessary to check the constraints catch up with the additional delays
that block deliveries due to the mailservers being busy with collecting
information and parsing messages.
marid-core-00 talks about "Negative Problem Statement" and the
"backdraws" of other proposals, but completely ignores the points
of its own backdraws.
A few comments about the backdraws of the other proposals:
MTAMARK:
It suffers from the fact that reverse DNS lookups are
poorly implemented in major fractions of the IP address space
What? "reverse DNS lookups are poorly implemented"? What the hell are
they talking about? I think they are talking about managing revDNS is
currently *neglected* ... wow, but managing XML records in DNS does
currently not exist at all. What do you think has a higher potential
of deployment, reactivating something that is currently neglected
but a well-established Internet technology for years and add
some simple TXT records containing a "1" to the reverse DNS
tree for about - how many outgoing MTAs do we have - 500000 hosts
or change/write/implement management software for some zillions of
domains were 98% of the domain owners will not be able to set up
correct XML information even if guided by programs. The more complicated
this XML stuff is the more error prone it is.
Changing ISPs will become an even bigger nightmare than it is currently
and the biggest problem will be to get MARID records right afterwards.
and from the fact that it's all or nothing: authority to act as an
SMTP client conveys authority to send absolutely any email,
legitimate or otherwise.
Exctly how does this differ from the XML approach? If there is a virus
infected or 0wned machine sending through the mail relay with the domain
of the office workstation it is all the same: it can send absolutely any
email, legitimate or otherwise. And as this XML stuff is so complicated
they will all put "wildcards" for the whole office to send in the DNS
and the 0wned office host may even send directly. Please don't talk
about firewalls and stuff or experienced admins now. If people had
firewalls and knew how to set them up and how to update software this
WG would not be needed at all.
And a point which is deliberately ignored is the problem of 0.10 USD
throwaway domains and short-TTL bot networks. Yeah, I know, this will be
solved anytime later with accreditation services.
CSV:
Is an SMTP client authorized to use a particular domain name in its
SMTP EHLO command? [CSV] attempts to answer this question. It
suffers from the fact that the EHLO name has a tenuous relationship,
at best, with the contents of any mail message.
So what? It is MTA authorization records not message authorization
records, even if the group morphed to it. A EHLO identifier is the
way one MTA tells another MTA about himself and his identity. It is
an important fact to know if this identity is faked. However this
could probably also partially accomplished by requiring the EHLO
to match at least one PTR record and have the forward lookup of this
record match the connecting IP (aka EHLO must match paranoid lookup).
RMX/SPF:
These suffer from the fact that the MAIL FROM address
really describes where to send NDRs to, and in many third-party and
forwarder situations this address is unrelated to the domain that is
resending the message.
This has not more or less backdraws than to check a Resent-From:
This provides no more or less authentication for a faked Resent-From:
of a throwaway domain and in that case if the message is not checked
during the SMTP transaction the bounce goes where to?
The faked envelope sender? To the SUBMITTER, which is an address
the originator of the message will never be able to check for mistyped
addresses. What have we won?
I know of some dozen installations, mostly bank types where the
MUA of the end user has NO CHANCE to check anything in DNS, as they
don't have access to external DNS information. Now, how is the outcome
of the XML checks signalled to the MUA? Will it work like in
http://weblog.infoworld.com/udell/2004/03/23.html? Now what have
we won?
IMHO this group has been blown away - by the XML hype and probably
overmotivation due to the time pressure - to Neverland and lost the
sight for reality.
I don't want to offend anyone, I know and respect that you work hard
and seriously to solve the problem, this is simply my impression after
coming back after two or three weeks and looking at things and how
they evolved with a bit more distance.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"