ietf-mxcomp
[Top] [All Lists]

Re: Backward compatibility with deployed SPF records (and choice of domain)

2004-06-25 23:21:36


----- Original Message ----- 
From: "Greg Connor" <gconnor(_at_)nekodojo(_dot_)org>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Saturday, June 26, 2004 1:27 AM
Subject: Re: Backward compatibility with deployed SPF records (and choice of
domain)



In a straight race, I would probably root for the non-prefixed records to
win, simply because the underscore might scare and confuse people (it was
removed from early versions of SPF for mostly that reason).  I do
understand the issue that the prefix is intended to address, but I don't
think the research we have shows it is anything to worry about.

Probably nothing, but there might be some ergonomic issues here.

The following was probably a customer misunderstanding, but recently I took
a customer survey to find out who has published SPF or MCEP (_EP.) domains
and how (access to DNS).  One customer provided the following reason for not
implementing the _EP host name for MCEP support.

----- Original Survey Message And Response ----- 

We need to know the following:

With WCSAP, it has the LMAP features, SPF and CEP.  Please check all that
applies:

[X] I have defined an SPF domain policy for my Domains in DNS
[_] I have defined an _EP domain policy for my DOMAINS in DNS
[X] I have not defined any for the following reason:
Please state reason:  My DNS host rejected the _EP entry as an invalid
host name.  I contacted their technical support regarding this and they
stated that the leading underscore was a violation of the rules.  When I
pointed out that this was a requirement for CEP as defined by Microsoft they
said they would look into it.  Currently they have not gotten back to me.

DNS manager:  You manage DNS as follows

[_]  Internal DNS server
[_]  Via my ISP using a DNS manager they offer
[X]  Other

www.dnspark.net

--- Back to me ---

Like I said, I'm sure it was a customer understanding, but it is happen
once, so I'm sure it will happen more.  From my standpoint, it was a
non-issue for implementation and it did take alittle extra "documentation"
to explain it.

Anyway, I don't see it as an issue because the way I see it down the road,
at some point we will be adding a Setup Wizard and Configuration to help
customers create the DNS/MARID entry either automatically or as a Cut/Paste
item to be sent to their ISP/DNS server provider, maybe via email for
example.

This is actually not a bad idea.  Back in the fidonet days, before a new
mail server was allowed to be put online and connect to the network,  he had
to install the compliant software and and then send an direct email (called
netmail) to his local area network mail host (akin to an ISP today I guess)
with a fix set of host registration information that got him into the
network node list (akin to DNS).  The network host then would test the new
mail server for network compliance and only then was his "address" (domain)
added to the world wide network node list.

I am not in no way suggesting this, but these day, it will help the mail
operator from A to Z, from installing/upgrading  a system, finding a MARID
compliant ISP to register with, sending DNS/MARID information to the ISP to
setup, etc.  And if the new pressures from the industry asking the ISP to
take more responsibility take hold,  the ISP might want to do some level of
"validation" or background checking before adding the information to his DNS
servers.

In Fidonet, it was a requirement for network membership. For the Internet,
it would just be an optional necessity and prudent/smart business move to
help minimize security/spam issues.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com