ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Dotless domains and email

2013-07-05 16:46:59


--On Friday, July 05, 2013 14:23 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

On 7/5/2013 1:56 PM, John Levine wrote:
All I'm saying is that there's a lot of existing and useful
practice which expects to be able to distinguish an alias
(presumably without a dot) from a FQDN. ...

Well, yes.  Take a look at SAC 053 and see if there's
anything they missed:

http://www.icann.org/en/groups/ssac/documents/sac-053-en.pdf


IMO, the report is wrong on an essential detail.  It
attributes the handling barrier to SMTP, which has no such
barrier.

Here's my summary of the situation:

      1.  SMTP does not prohibit dotless domains.  So, as far
as the protocol is concerned foo@example is as legal as
foo(_at_)example(_dot_)com.

      2.  A wide range of independently-developed
mail-receiving software treats a dotless hostname as /not/ a
legal domain name and thereby filters it out as potentially
hostile.  A common example that justifies this is 'localhost'.

      So there is indeed a widespread, very solid email
barrier to usage of dotless hostnames, although it is from
long-standing receiving software practice, rather than from
the protocol specification.

This has been noted by others but, for purposes of completeness
in the above summary (and following Dave's outline as closely as
possible), 

     3. A wide range of independently-developed mail-composing
and sending software will treat a dotless hostname as an alias
or partial name and apply completion or other local rules to it.
Depending on the client and configurations or other
circumstances, those rules may either be part of a DNS searching
process or more locally determined (e.g., looked up in an
outbound alias table).

I think the correct statement would be that, independent of what
different versions of the SMTP spec say, or appear to say,
common and perfectly reasonable local practices at both the
sending and receiving ends make the interpretation of dotless
domain-parts sufficiently unpredictable that depending on them
to work is unwise and might easily cause security and/or
stability problems.

  best,
     --john



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp