--On Monday, February 15, 2016 18:17 -0500 Paul Wouters
<paul@xxxxxxxxx> wrote:
> On Mon, 15 Feb 2016, John C Klensin wrote:
>
>> Because of that history and consensus, the strong suggestions
>> in 5321 are about as far as one is going to get as far as
>> restrictions/ recommendations on the mailbox names themselves
>> and the "don't try to guess" rule probably isn't going
>> anywhere.
>
> The failure of that community is pretty big and it is clear
> that the
> (non)rules that came out of that failure are _still_ causing
> us problems.
> It has itself delayed this 3 page document for over a year
> without any substantial new input or insights.
Paul,
You won't get agreement from many of us that it is even a
failure. As I said in my earlier note, the decision by the
community (generally and email-specific) that senders are not
allowed to make assumptions that anything matches a mailbox name
other than the mailbox name itself has protected us from a
complete mess wrt internationalization (see Harald's example).
That same decision was critical to allowing gateways based on
Internet mail to work well with a wide variety of other email
systems, sometimes turning into the preferred transport between
islands of identical, but differently-configured, systems. FWIW,
the "no one but the delivery server gets to interpret an
address" rule of the applications layer application of the
robustness principle is the latter principle at its best, at
least until would-be senders starting reading the requirement to
be liberal about what is accepted as "recipients are 'required'
to accept whatever nonsense we throw at them".
I don't suggest that SMTP is perfect. Most of us have some
things we would change if we were starting over today (as you
might guess, the rule about senders not interpreting address
variations is not on my personal list). But Internet mail is on
the short list of our most widely-deployed and wildly-successful
protocols. From my perspective, the very wide deployment of
SMTP/ IMF mail that makes it attractive to provide better ways
to secure it (if it were not deployed and in use, you presumably
wouldn't care) makes it incumbent on the DANE WG (and anyone
else proposing improvements) to design those improvements to
work well with the mail environment as the mail environment is
actually defined, deployed, and working.
If your position is, instead, that the email community screwed
up (or "failed") to produce a protocol specification that was
convenient for how you (and presumably the DANE WG) would like
to do things now, then mine shifts as well... from "if you folks
want to try an experiment to see how it works and how much it
deploys, then go for it as long as the spec is clear on
mechanisms and assumptions" to "DANE is living in an alternate
reality and the IETF should not approve this spec, even as
Experimental, without a convincing demonstration that it will
not lead to damage to the mail system or to an increase in bad
SMTP implementations".
As John Levine points out, it is not as if there are no
plausible alternatives that would work at least as well or
better from an email (real SMTP email, as defined, implemented,
and deployed) standpoint. In addition to the example he gives,
there is a possibility that has been discussed on and off for
decades. That is to simply define an SMTP extension that builds
on the original motivation for VRFY and allows asking the
relevant delivery server (even in a multi-hop environment) if it
has a public key it would recognize as associated with a given
address and, if it does, what the canonical form of the address
is and what the key is. There are issues with that too, but
they doesn't get us tangled up with the difference between DNS
and email comparison functions or require that we modify the
mail specifications and environment in order to make a
key-finding function work.
> Two problems we do not have:
>
> 1) POSTMASTER@xxxxxxxxxxx has been delivered to
> postmaster@xxxxxxxxxxx
> since Network Solutions was the only Registry in town.
Actually, there was controversy about that many years ago that
has nothing to do with Network Solutions. That is why RFC 2821
Section 4.5.1 imposes a specific requirement that "Postmaster"
be accepted as case-insensitive. IIR, case-independence for
Postmaster was widely assumed before 2821 but 2821 was the first
time the rule was specified in an IETF (or predecessor)
consensus document. It is also clearly stated as a special
case, not a general comment about case-independence.
> 2) No sentient organisation hands out a LHS with only case
> differences
> to different entities (eg PAUL@xxxxxxxxx is realistically
> guaranteed to be paul@xxxxxxxxx).
You may think so, but your position is not supported by either
the text in 5321/5322 (or their predecessors) or practice. I
would agree that it is generally ill-advised, and would agree
with or make snarky comments about "security by obscurity" (and
have done so), but I've seen just that done, most often in cases
in which one form leads to different behavior than the other
even if both are accepted. At least some of the reasons are
similar to some for using subaddresses: if one can match a
sender (backward-pointing) address to the particular stylistic
form that sender is expected to use, it is possible to easily
exclude a good deal of spoofed mail. As to whether the mail
administrators or organizations who have done that are sentient,
I don't think that is a debate you want to have.
> I find any efforts rejecting a solution because it does not
> support
> the above two corner cases to be an exercise in dogma rather
> than engineering.
You are of course entitled to your opinion. See above for parts
of the explanation of why some of us may not agree with you.
> Two real problems we do have:
>
> 1) Phone virtual keyboards and language settings
> auto-capitalizing
> recognised names (probably a bigger problem in the
> US-ASCII world)
> 2) Browsers in webforms auto-capitalizing recognised names.
> (probably a
> bigger problem in the US-ASCII world)
> I find any efforts ignoring these two things happen at an
> almost daily
> rate for those people who use smart phones to be dogma instead
> of engineering.
But no one is "ignoring" either and the email specification were
not ignoring them even before there were phones with keyboards
or browsers. That is one reason why the robustness principle
exists and applied to email. More specifically, it is why 5321
was intended to be clear that it is generally wise for delivery
MTAs to accept mailbox local part name variations that users
would expect to work -- whatever those uses might think of as
case-independent matching included. If they do that, then the
cases you mention above "just work". But "generally wise" (and
even "SHOULD avoid" from RFC 5321 Section 4.1.2) are far from
"MUST" do things that way.
The problem with the dane-openpgpkey proposal isn't either of
the two cases you cite. It is that it requires a sender to
guess at the form of a string that will be accepted by the
delivery MTA and, if the delivery MTA makes a distinction (one
that it is allowed to make) about a canonical or preferred form
of that string, what that is.
> Then we have two contradicting requirements from the SMTP
> world:
>
> 1) One must only use the _exactly_ inputted local-part
See above. That isn't an SMTP requirement as far as SMTP is
concerned because the delivery MTA is free to accept any
variations it likes. The prohibition is on guessing at
transformations of the local part in the originated MUA,
Submission Server, or intermediate MTAs and expecting that the
mail will still go through.
> 2) One is not allowed to use more than 1 lookup or else it
> qualifies as "illegal local-part guessing"
Not an SMTP requirement. As far as SMTP is concerned, guess all
you like. Some anti-spam, rate limiting, and other systems may
be fairly hostile to your doing much of that, but it isn't
"illegal", especially as far as SMTP is concerned. There is
also, historically (much less used today but not deprecated), a
command that not only facilitates local-part guessing but
facilitates discovery of canonical names and/or preferred
forwarding addresses. It is called VRFY and has been around
since RFC 821.
> While I can sympathise with the desire to support UTF-8, EAI
> and
> everything else in the local-part, I have done my best
> contacting
> people who were involved with EAI and to put their advised text
> into the draft. If you have improvements to those texts, please
> share them with us.
I don't know who you contacted, but, as co-author of the
"framework" specification and co-chair of the WG at the time the
standards-track documents were completed, I don't think you
asked me. The omission of the normalization issue --something
that was extensively discussed in the WG-- suggests that
whomever you did consult was either asked the wrong question,
was not paying adequate attention to the details, or that your
interpretation of the "advised text" did not fully capture their
advice. I hope it is not necessary to dig further into those
details: the document text that is relevant is what is in the
document in IETF LC and that text is, at least IMO, insufficient
from an i18n standpoint regardless of how it got that way.
> I have indicated I would be completely fine with saying
> anything from
> "anything non-ASCII" should not be lowercased to "anything
> non-ASCII
> should be lowercased using [ruleset donated by those people
> object to
> the current text]" to "try unmodified, then lowercased". The
> only
> unacceptable option to me is "try only what was input by user
> and ignore all common problems associated with that".
But the latter is, for reasons several others have explained
better than I can, the _only_ option that is consistent with
what SMTP allows a sender or an agent for a sender to do. If
you don't like it, propose a modification to 5321. More
specific objections to each of your preferred options have
appeared in earlier notes but the bottom line, for me, is that
your spec should either be fully consistent with the language
about address interpretation in RFC 5321 or it (or a
supplemental, normatively-referenced document) should try to
update and change 5321.
If neither consistency with 5321 nor updating 5321 is acceptable
to you and the WG, withdraw the document.
>> Nothing I'm aware of
>> (other than probably the WG Charter) prohibits DANE from
>> proposing an update to 5321 and 6530ff, but the history (and
>> probable side-effects that no one has tried to analyze)
>> predicts that the idea won't easily get community consensus.
>
> To put it bluntly, I'd rather commit to 800 hours of unsedated
> dental drill work than to go anywhere near discussing RFC 5321
> related items within the IETF ever again. But I would be happy
> to watch the fireworks from far far away if you wish to take
> on that work.
To be equally blunt, absolutely no one in the community who has
been actively involved with the development of 5321 and its
application has come forward to support the changes you would
apparently like or to volunteer to do the work. I won't presume
to speak for others but, at least in my case, that is in large
measure because I think those changes would be a bad idea.
Assuming you aren't going to change your attitude toward dental
drills or the solution that I believe is the only one that is
fully 5321-compliant and further assuming that you and the DANE
WG are sincere about this being an experiment, I suggest what
has been suggested before:
(1) As Harald suggested, define the participants in the
experiment so that any mailbox address or site that does
not conform to whatever assumptions you want to make is
simply excluded.
(2) In addition, define the experiment as applying to
all-ASCII mailbox names only so that SMTPUTF8-style
addresses (and messages) are not supported and you don't
need to figure out how to deal with this complications
at this stage.
Going that route requires that you and the WG very clearly
recognize this as an experiment -- not just as a category of
RFC, but as a specification that will require more work and
almost certainly some substantive changes to be acceptable as a
Proposed Standard even if the experiment itself is judged to be
completely successful. But that may be a reasonable choice.
best,
john