Good points Ned.
I'm more interested and I'm sure other SMTP vendors, in dealing with
external interfaces and how to handle it best in an anonymous world.
Internal operations (AKA authorized connections) are always different.
I have to check our default local policy logic, but I think it all
depends which domain we referring too - the HELO/EHLO, MAIL FROM and/or
--On Friday, March 23, 2007 00:03 +0100 Frank Ellermann
> We could argue forever about this, some folks elsewhere
> even think it's a good idea to modify ABNF discussed for
> years in AUTH48, but actually you've only three choices:
> 1: Allow the trailing dot everywhere no matter what 2821
> and 2822 say. Maybe say "SHOULD have a dot" for TLDs.
> 2: Keep it as is in 2821, no trailing dots, and one dot
> required. This excludes TLDs, unlike (2)822.
> 3: Same as (2) with a special rule for TLDs: TLDs MUST
> have the trailing dot, other domains MUST NOT have the
> trailing dot.
> The 3rd choice is not KISS, and it has a high astonishing
> factor. Excluding TLDs in the 2nd choice is also somewhat
> astonishing, my question about it (2004-11-12) was if this
> is a typo, and you said "intentional". 1st and 2nd choice
> are KISS.
There is a fourth possibility and it seems to be where we are at
present. That is:
4) One-label names permitted, no trailing dot ever. If a
single label name is used, it represents a TLD if sent between
SMTP servers. In input to a submission server, the client must
agree with the server on some method to distinguish between an
incomplete domain name and a TLD. Several such methods are
possible; all are outside the scope of this specification.
I am in favor of this option 4. The one clarification I would make is
that the restriction applies between servers in different administrative
domains. SMTP is used inside administrative domains all the time in
all sorts of wild and wonderful ways that really aren't our concern.
P.S. I speak as someone whose implementation is fully capable of parsing
trailing dots and treating their presence or absence differently in
both routing and output. Just because my code handles this mess is no
require others to do it, especially since it represents a change from
standards in the area.