Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Wed, 8 Jun 2005, Ned Freed wrote:
> > A practical issue I have with this doc is that the recommendations are
> > relatively few, and most of them are rather generic or vague.
> > Haven't we learned more on email BCPs by now?
> What we have learned and what we are able to reach consensus on are two very
> different things.
My point is that when we are writing a document like this, making it 
intentionally very generic and vague seems much less useful.  It may 
be difficult to get to a consensus what the BCP should be, but 
hopefully what people have learned could be documented in a 
non-normative way (i.e., a list of tradeoffs/background information). 
This could be accompanied in a "Discussion" paragraph or two for each 
vague item, for example.
> > For example, this document says nothing on backup MX's accepting 
> > mail for accounts which do not exist, just a very generic:
> >    o  MDAs SHALL NOT accept mail to recipients for which that MDA has no
> >        arrangement to perform delivery.
> No doubt because I've seen no consensus whatsoever as to how this 
> (very thorny) issue needs to be handled. If there is an agreed best 
> current practice here waiting to be documented I'm unaware of what 
> it is.
So, one could at least describe the non-existence of such best 
practice?
> > One generic question: what about the case where an organization X has
> > backup MX at ISP Y?  How will that reflect to:
> >     o  For email being received from outside their local operational
> >        environment, email service operators MUST distinguish between mail
> >        that will be delivered inside that environment, from mail that is
> >        to be relayed back out to the Internet.  This allows the MTA to
> >        restrict this operation, preventing the problem embodied by "open"
> >        relays.
> It means the backup MX needs to be able to distinguish addresses 
> associated with the destination environment and addresses that 
> aren't. This functionality is readily available in most mail 
> software.
I didn't make this point clearly, so let me try to state the initial 
issue: "MUST distinguish between mail that will be delivered" seems 
ambgiuous enough so that it could mean only that the server is 
responsible for example.com, not that the server needs to know all the 
user(_at_)example(_dot_)com accounts which will be used for final delivery. 
As the document's use of basic terms like "delivery" are not 
unambiguous enough, careful wordsmithing and clarification appears 
to be needed.
If the interpretation is what you write, more verbiage could still be 
helpful.  Is this really available in most mail software?  I at least 
would appreciate such feature and must have missed it so if you know 
how to do this w/ sendmail for example, I'd appreciate an example 
(off-list).
> > Mostly editorial comments:
> > 1) Is the scope of the title, "Email Submission Between Independent
> > Networks", too narrow, as the document discusses relaying and delivery
> > BCPs as well?
> But both are discussed within the context of messages being sent between
> networks.
Maybe we agree then that the document actually talks about more than 
just mail submission? (and the title is not accurate)
> > 2) The document specifies in a couple of places that authentication
> > MUST be performed, but does not specify _what_ kind of authentication.
> > This is then discussed a bit in Section 5.  I note that there is no
> > mandatory-to-implement authentication mechanism (or at least it isn't
> > spelled out), so interoperability may be hampered.  Should this
> > document try to specify such?
> IMO it is entirely inappropriate for this to be done in a BCP 
> document of this sort. If this is done at all it needs to be done in 
> a revision to the SMTP protocol specification. (And good luck 
> getting agreement on a mandatory-to-implement scheme.)
Well, I guess we have to disagree on that, though I agree that getting 
consensus might be difficult. (It doesn't have to be just one, of 
course, but it has to reflect to the reality.)
This doc makes MUSTs on authentication mail submission, and treating 
unknown mails as mail submission.  That calls *very* strongly for 
defining a set of commonly implemented and interoperable auth 
mechanisms, otherwise submission just doesn't work.  As this doc 
specified the requirements, it seems the responsibility also exists to 
define how to actually achieve it.
> 3) The following text:
>
> >     For example, SMTP AUTH using a secure authentication method like
> >     CRAM-MD5 or DIGEST-MD5 may be sufficient.  However, in some
> >     environments, it is impractical to use one of the secure methods,
> >     meaning that SMTP AUTH would be transmitting the username and the
> >     password in clear text over insecure networks.
> > .. seems to be confusing.  First you say "a secure authentication
> > method", but then you say using such would be impractical because the
> > password would be sent in the clear text.
> That's not what it says at all - the "because" is entirely your own 
> invention.
Thus even more reason for making it clearer.

> I reallly don't think it is all that unclear. However, I do think 
> that the prose could benefit from some more detailed discussion of 
> the specific threats and security issues involved, especially in 
> light of the recent spate of attacks where the credentials for huge 
> numbers of users have been stolen in one swell foop. I believe the 
> authors have requested specific information from the security folks 
> in order to do something along these lines.
Good.

> However, I do not believe there is any
> requirement for "null" IANA considerations sections.
As was already mentioned, this is in the ID-guidelines.  For the 
record, I thought it was silly myself, and asked the IESG, "can't we 
just redefine the IANA considerations so that if any IANA action is 
needed, the document must include the considerations section." 
(previously, it wasn't needed unless a new registry was created)  But 
it seemed that would cause late surprises for folks that don't realize 
they should have inserted the section..
--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf