Hi !
* Eric S. Raymond <esr(_at_)thyrsus(_dot_)com> [2003-10-16 20:50]:
Phil White <spf(_at_)radagast(_dot_)itmagic(_dot_)ltd(_dot_)uk>:
3) The Sender rewriting scheme.
I'm sorry. I think this is horrible, and just plain ugly. It seems far too
complicated, and therefore prone to breaking. I cannot stress this one
point
too strongly. Sorry.
He's got a good point. It is ugly.
Yes, but just ignoring the problem is not the right solution.
1) Do precursors of MX still exist?
RFC883 designated the RR's of
[ Describtion of MD, MF, MR, MB and MG records ]
All seem to work OK under BIND, so I assume this is an obsolete record that
still officially exists If it exists, can these RR's not be used for
Officially they don't exist anymore.
As Loic Prylli mentioned in <3F900C1C(_dot_)1070503(_at_)abbloi(_dot_)org>
(http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200310/0253.html)
it is not allowed ("... servers MUST NOT load ...") to use them.
(RFC 1123)
And even in RFC 1035 the RR MD and MF are converted to MX RR:
[...snip...]
MD is obsolete. See the definition of MX and [RFC-974] for details of
the new scheme. The recommended policy for dealing with MD RRs found in
a master file is to reject them, or to convert them to MX RRs with a
preference of 0.
[...snip...]
MF is obsolete. See the definition of MX and [RFC-974] for details ofw
the new scheme. The recommended policy for dealing with MD RRs found in
a master file is to reject them, or to convert them to MX RRs with a
preference of 10.
[...snip...]
That means BIND is ignoring the RFCs.
something useful? If these RR's are obsolete, but still allowable by
reolver
libraries, we have a plethora of useful options here. Even the definition
for
MD seems appropriate. Though it was written to imly that this was the host
receiving mail (AFAIK), it could eaqually be taken that the MD host is
authorised to send mail for that domain (Mail Delivery?)
Because it works for you doesn't mean it will work for other user with
different software. When you use software which follws the RFCs you'll
not be able to use SPF.
I like the idea of re-using MD.
I think it would be a good idea to use our own RRs.
But there are two options:
a) use TXT RRs and (hopefully) get a fast implementation of SPF because
using TXT RRs doesn't need sofware updates. And DNS admins can
maintain their zones even if they don't control the DNS software.
b) get a new RRs (or reuse an old one). I like the idea of a new RR
(personally I prefer a new over reusing an old one), but in any case
we have to get an official RR. Maybe that will not take much time and
even the patches for the software might be released very fast. But
forcing your admin to use the software will take time. Take a look at
the server software around: old versions are in use everywhere. Even
if they are buggy and can be exploited. If admins are to lazy to
update a software which is a *security* risk, why should they update
it when it only supports a new feature (which in most cases they are
not going to use)? Because their user want that? Hm, hard to believe.
When we have to modify a standard for SPF to work, we should start
with SMTP, which would be the best place. So considering a new RR
means (IMHO) to think about a new SMTP RFC.
mfg @ndy
--
personal web site: http://skater.priv.at/~andy/
Nachtskaten / Friday Night Skating Vienna: http://night.skater.priv.at/
Informationen zum oesterreichischen Usenet: http://www.usenet.at/
Verein fuer Internet-BEnutzer Oesterreichs (.AT) http://www.vibe.at/
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com
pgp3fZ0eZRYSZ.pgp
Description: PGP signature