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

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Jun 2005 19:38:39 -0400

First, in section 5, please do not list cram-md5 as a secure
authentication technology.  Today I think we'd require a security
layer from a SASL mechanism to consider it secure.  Also cram-md5
suffers from other defects.

Also, I'm a bit concerned about the following requirement:

   o  Mail coming from outside an email operator's local environment,
         and having a RCPT-TO address that resolves to a destination that
               is also outside the local environment, MUST be treated as mail
                     submission, rather than mail relaying.  Hence it must be subjected
                           to mail submission authorization and validation checks.

The good part of this requirement seems to be to subject such mail to
authorization (and in many cases authentication).  However I think
that saying mail must be treated as submission rather than relaying
may have effects significantly beyond authorization/authentication.
For example MSAs are given significant freedom to modify submitted
email--appending disclaimors and doing all sorts of things.  I'm not
convinced such is appropriate in this instance.  Also, mail relaying
and submission have different protocols defined by different
specifications.  For the most part these protocols are interoperable
but the requirement seems overly strict given this situation.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Fri, 3 Jun 2005 17:27:55 -0700

Sam,

>  suffers from other defects.

1. You mean that MD5 is not a common, current practise that provides a useful 
degree of security?

2. Taking note of the exact language used in the sentence citing MD5 -- 
specifically the "may be sufficient", please supply alternative language.

>  submission, rather than mail relaying...
....
>  For example MSAs are given significant freedom to modify submitted

That's right.

The implications you are drawing are exactly what is intended.  When the 
document said "treat as a submission" it meant exactly that.  

In other words, if you are coming from outside the network, you do not get to 
"relay" through the network.  You can post/submit from within, you can deliver 
into the net or you can post/submit from outside.

>  convinced such is appropriate in this instance.  

Well, it certainly is a point that one could imagine deciding in either 
direction, in the abstract.

So, yes, it is important that the folks who have been working on this document, 
and contributing to discussions about it, have extensive operations experience 
and made the choice intentionally. 

Are you raising a concern that the specified behavior will not work -- ie, it 
has a core, technical or operational flaw?  Or are you simply expressing your 
concern that it is more strict than you would prefer?

>Also, mail relaying

SUBMISSION is relatively recent and it's use is still only for a portion 
of the posting traffic on the Internet.  From a practical standpoint, port 
25 is still heavily used; so that the two types of traffic are still 
frequently multiplexed over 25.  Hence any BCP concerning initial posting 
needs to cover both ports.

That said, it is the presence of the submission port as an alternative to 
port 25 that permits the document to be so forceful about both requiring 
authentication on the submission port and prohibiting its blockage.

In other words, the strictness of the spec was rather carefully discussed.  
It represents a moderately hard-won balance among the authors (and, by the 
way, the rest of the folks contributing to discussion during development 
of the spec.)  There are good arguments for being even more strict, but we 
wanted the document to have the widest support possible.  So, relative to 
much of the email operations community, the strictness you are reacting to 
is actually rather moderate...

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 04 Jun 2005 05:21:30 +0200

Dave Crocker wrote:

> 1. You mean that MD5 is not a common, current practise that
>    provides a useful degree of security?

The SASL-registry says "limited" for CRAM-MD5 and "common" for
DIGEST-MD5, whatever that means.  I know an MSA offering...

AUTH PLAIN LOGIN CRAM-MD5

...s/CRAM-MD5/OTP/ or similar in the text can't be a good idea.
 
> 2. Taking note of the exact language used in the sentence
>    citing MD5 -- specifically the "may be sufficient", please
>    supply alternative language.

Maybe s/secure/encrypted/ in this sentence is an alternative.

What you really want is probably "stay away from LOGIN or from
PLAIN outside of TLS", and CRAM-MD5 is still better than PLAIN
LOGIN, or than SMTP-after-POP (for APOP or a plain USER PASS).

                          Bye, Frank

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Jun 2005 19:03:25 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> Sam,
    >> authentication technology.  Today I think we'd require a
    >> security layer from a SASL mechanism to consider it secure.
    >> Also cram-md5 suffers from other defects.

    Dave> 1. You mean that MD5 is not a common, current practise that
    Dave> provides a useful degree of security?

No.
    Dave> 2. Taking note of the exact language used in the sentence
    Dave> citing MD5 -- specifically the "may be sufficient", please
    Dave> supply alternative language.

That sentence recommends both cram-md5 and digest-md5.  I think
digest-md5 is fine; I think cram-md5 is not.  I'd like to ask that you
simply drop the word cram-md5 and appropriate conjunctions.

    >> o Mail coming from outside an email operator's local
    >> environment, and having a RCPT-TO address that resolves to a
    >> destination that is also outside the local environment, MUST be
    >> treated as mail submission, rather than mail relaying...
    Dave> ....
    >> The good part of this requirement seems to be to subject such
    >> mail to authorization (and in many cases authentication).
    >> However I think that saying mail must be treated as submission
    >> rather than relaying may have effects significantly beyond
    >> authorization/authentication.  For example MSAs are given
    >> significant freedom to modify submitted

    Dave> That's right.

    Dave> The implications you are drawing are exactly what is
    Dave> intended.  When the document said "treat as a submission" it
    Dave> meant exactly that.

    Dave> In other words, if you are coming from outside the network,
    Dave> you do not get to "relay" through the network.  You can
    Dave> post/submit from within, you can deliver into the net or you
    Dave> can post/submit from outside.

    >> email--appending disclaimors and doing all sorts of things.
    >> I'm not convinced such is appropriate in this instance.

    Dave> Well, it certainly is a point that one could imagine
    Dave> deciding in either direction, in the abstract.

    Dave> So, yes, it is important that the folks who have been
    Dave> working on this document, and contributing to discussions
    Dave> about it, have extensive operations experience and made the
    Dave> choice intentionally.

As you are no doubt aware, this document is an individual submission
for a category requiring IETF consensus.  It's perfectly reasonable
for experts in operating the mail system to propose this initial
position.  It's also reasonable for members of the community
(including myself) to ask those experts to justify their position.
Ultimately, the AD sponsoring this individual document will need to
determine what the informed community consensus is.  

I'm asking for that review.  I'd like to know:

1) What the implications of treating out-of-network mail injection as
   submission are.  In particular, what would be the difference
   between treating this as submission and treating it as relaying
   with a requirement for authentication/authorization?

2) Why is this the right course for the Internet?

As you are aware, 2119 musts are fairly strong; we use them only when
we have sufficient security, operational or interoperability reasons
to do so.  It's not obvious to me what the operational justification
of this must is.  Fortunately, since the issue has been discussed by a
group of experts, it is obvious to someone and they can tell us all.

Thanks,

--Sam

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Jun 2005 13:37:30 -0700

Sam,

>  simply drop the word cram-md5 and appropriate conjunctions.

OK.  That's certainly a specific suggestion.

Since this exchange is on the public list and since I do not track the 
fine-grained details of which security algorithms are currently viewed as safe, 
could you summarize the current state of use and safety (or lack of either) 
cram-md5.  

I press for this because I recall some recent stuff about algorithms that have 
long-term exposures, but not much near-term, practical weakness.

>  (including myself) to ask those experts to justify their position.

Indeed it is.  And I certainly hope my response did not imply otherwise.  

Rather it was merely seeking to make clear that the document did have quite a 
bit of broad-based email operations input in its formulation.  

As we have all seen, there are jillions of clever people, with many more 
jillions of clever ideas and even more theoretically reasonable ways to resolve 
issues with those ideas.  

So my point was that this was very much NOT produced by the whim of yet-another 
individual clever writer, instead being driven by a diverse group which, in 
turn, is entirely driven by operational pragmatics.

>  submission are.

Unfortunately, you are asking an entirely open-ended question and I do not know 
what "implications" you are looking for.  

What I DO know is that, indeed, we are documenting a common, current practise 
and that it works well.  I can't say that I have heard of any negatives about 
it, but I don't do line ops so I will leave it to others to cite any real-world 
problems that are created.

I DO know what happens when there is unauthenticated relaying that originates 
from outside one's network.  What happens is that you get blacklisted.  It is, 
after all, what the term "open relay" refers to and what is so popular with mass 
spammers.

> In particular, what would be the difference

The major difference is accountability.  When a message is treated as a 
submission, then the submission agent (MSA) is able to take a reasonable degree 
of responsibility for the (new) message.  For simple relaying, such 
accountability is essentially impossible.

>  2) Why is this the right course for the Internet?

See discussion of open relaying, above.  If the problem with open relays needs 
more discussion, please let us know.

Simply put, the open Internet's email infrastructure is under attack.  The 
postal mail global infrastructure, and all of the large-scale services that do 
global transfers, are subject to a high degree of accountability for their 
activities and they have a significant degree of control they impose at their 
boundaries.  By contrast, Internet mail is entirely open, with no trusted core.  

The (unfortunately predictable) development of abuses of this service are 
requiring development of practises that tighten things up.  The challenge is to 
do this in a way that does not create some sort of centralized control.  

The current document specifies a fairly modest set of steps to increase the 
legitimate accountability of services that are injecting mail into the open 
Internet.  And, to repeat: it is based on a set of relatively common practises 
that are intentionally chosen for their lack of controversy in the email 
operations community.

d/

  d/
  ---
  Dave Crocker

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Jun 2005 13:27:01 +0300 (EEST)

On Fri, 3 Jun 2005, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the
> following document:
>
> - 'Email Submission Between Independent Networks '
>   <draft-hutzler-spamops-04.txt> as a BCP

This seems a good document, but could probably still use a bit of 
polishing.

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?  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.

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.

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?

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?

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.

This is not good.

I doubt the IETF is OK with calling such authentication methods 
"secure".  Secure authentication methods _don't_ send stuff in the 
clear text, period.  I think this paragraph, and maybe more, needs 
some serious editing.

4) As process nits:

7.2  References -- Informative

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

.. RFC2119, when used, must be a normative reference.  Likewise, 
you'll need to add a "null" IANA considerations 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

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Jun 2005 07:50:24 -0700 (PDT)

> This seems a good document, but could probably still use a bit of

I think you seriously underestimate the difficulty getting consensus on these
"polishing" issues.

> 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.

> For example, this

>        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.

>        restrict this operation, preventing the problem embodied by "open"

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.

> Networks", too narrow, as the document discusses relaying and delivery

But both are discussed within the context of messages being sent between
networks.

> 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.)

> password would be sent in the clear text.

That's not what it says at all - the "because" is entirely your own invention.
More specifically, the usual reason it may be impractical to use CRAM-MD5 or
DIGEST-MD5 is that both require cleartext-equivalent or
near-cleartext-equivalent password storage on the server, which may be (a)
Incompatible with existing password stores or (b) Seen as a security exposure.
This has nothing to do with the fact that SASL PLAIN sends passwords in the
clear.

> clear text, period.  I think this paragraph, and maybe more, needs

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.

> you'll need to add a "null" IANA considerations section.

Agreed on the RFC 2119 reference. However, I do not believe there is any
requirement for "null" IANA considerations sections. (A scan of recently
published standards track RFCs turned up several that don't have such a section
- 4022, 4015, etc.) Aren't we paddding out our documents with enough useless
boilerplate already without adding yet another useless section to the mix?

				Ned

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Jun 2005 14:05:50 -0400

Pekka is correct: a null IANA section is required for internet drafts.
It is stripped in the RFC process.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Jun 2005 14:26:13 -0400

--On Monday, 06 June, 2005 19:03 -0400 Sam Hartman
<[email-masked]> wrote:

>...
>    Dave> 2. Taking note of the exact language used in the
> sentence     Dave> citing MD5 -- specifically the "may be
> sufficient", please     Dave> supply alternative language.
> 
> digest-md5 is fine; I think cram-md5 is not.  I'd like to ask
> that you simply drop the word cram-md5 and appropriate
> conjunctions.
>...

Sam,

With the understanding that CRAM-MD5 was originally specified as
a quick hack to provide a low-infrastructure alternative to
clear-text passwords --a sort of "better than nothing
authentication" in its time and that I'm not especially attached
to it despite having my name on the RFC...

This business of comfort with digest-md5 and discomfort with
cram-md5 comes up regularly.  So, far, each time it has been
probed, the answer has ended up being that the added security
associated with the digest form is, in practice as distinct from
theory, fairly marginal.  That might be uninteresting were it
not for another, possibly inconvenient, observation: I don't
have hard data on this but my subjective impression from having
watched the market is that CRAM-MD5 is much more widely
supported in both SMTP authentication and in its POP3 and IMAP
variations than the digest form.

I don't pretend to be a security expert, so let me describe the
situation as I think it has been explained to me in the hope
that you (and others) will comment in somewhat more precise
technical depth than "...I think cram-md5 is not".

In a more perfect world, we wouldn't use shared secret
authentication models at all.  Regardless of how the secrets are
exchanged or verified, they have a number of weaknesses as
compared to, say, systems based on good PKI environments, good
certification and trust models, close binding of user identities
with credentials, users who understand how to manage private
keys (and passphrases, etc.) and never lose them or handle them
in ways that could create doubts about the control and ownership
of such keys, and so on.  Those PKI-based and similar strategies
would, of course, be easy to implement in a secure way and would
not add significant code footprint, execution time, or
operational or implementation complexity to either the relevant
clients or servers.

I hope we can agree that the world is not that perfect or, at
least, that we aren't there yet.   Perhaps someday.

Until we get there, we are stuck in the world of shared secrets,
whether in the form of passwords or something more complex.  At
least to some of us who are outside the security community, that
world involves a rather simple tradeoff:

	* If the server host is more trusted than the network,
	then we prefer "prove that you know the secret"
	approaches that avoid transmission of the secret itself
	across the untrusted network.  Most of those "prove that
	you know the secret" approaches depend on hashes of more
	or less complicated strings.  They also require that the
	server, as well as the user, have the secret more or
	less in clear text in order that those hashes can be
	computed.  There are methods around that use different
	approaches, but they increase either complexity or the
	number of handshakes significantly.
	
	* If the network is more trusted than the server, then
	we are, surprisingly, better off with passwords than
	with hash/ "proving" techniques, since the version of
	the secret on the server can then be protected by
	aggressive one-way hashing or encryption.  Within this
	framework, we can try to make the network even more
	trusted, but the really effective ways to do that
	require either that the client machine already know, and
	know securely, the key arrangements of the server
	(impractical for email and many other applications) or
	we end up back into the PKI problem and ideal worlds.

Curiously, at least one popular way to protect network traffic
and make the network more trusted illustrates the problem:
classic uses of SSH give the user (or system administrator) a
choice between using key arrangements that must be known in
advance on both machines and which create a vunerability if the
client machine and keys fall into the wrong hands or use of a
password-like arrangement that is more easily guessed than a
long key (the tunnel that protects the password is not a useful
defense against password-guessing attacks).   I think even many
of us non-experts at least understand the issue and tradeoff.

Supposing that I'm designing an application and I decide that
the public key route is not appropriate for my environment.  I
also decide --correctly or not-- that I trust my servers
significantly more than I trust the network.  So I decide to go
with a shared-secret plan that doesn't involve transmitting the
secret across the network in clear.  

Now I have two problems.  The first is whether the mechanism I
use to test knowledge of the server across the network is good
enough.  There, picking up on Dave's note, the key is MD5
itself.  We were told when we did CRAM-MD5 that using a keyed
model would provide significantly more security than the basic
hash, with small incremental computational cost.  Paul Krumviede
understood that argument and agreed with it; I really didn't,
but I trusted both the advice and Paul.  The digest approach
came onto the radar for this purpose a bit later, but, if I
recall, we never got an argument that it was significantly more
secure in terms of protecting the network transmission (and Paul
is, unfortunately, not around to participate in that
evaluation).  RFC 2617 does state that the digest method is
"significantly stronger than CRAM-MD5", but it is a little short
on explanation of attacks, metrics, etc., by which that
assertion can be judged. If the digest-based technique isn't a
_lot_ better than simple keyed-MD5, then perhaps it is time that
you folks tell us what we should be using instead of MD5-based
approaches and we should be working together to get it
deployed... as long as it doesn't require extra turnarounds or
public key utopia.

My other problem is what I do to protect the secret on my
server.  Now remember that, in getting this far, I have already
decided I'm willing to trust my server more than I trust the
network.    There are a number of interesting things I can do,
some of which may be operationally very effective and none of
which are visible in the protocol (which means an attacker has
the added problem of figuring out just what I am doing): I'd
need to be pretty overconfident, and pretty stupid, to put a
collection of name-value pairs in
/etc/cram-md5-cleartext-secret-file.

As the abstract to RFC 2617 puts it, "As with most other
authentication protocols, the greatest sources of risks are
usually found not in the core protocol itself but in policies
and procedures surrounding its use."   It is my suspicion that
the differential potential for risk associated with the protocol
nature of these two methods is overwhelmed by the potential
risks associated with poor operational decisions... and that the
IETF community has not been especially helpful about making
recommendation for good operational policies with either.

If we look further at that server vunerability, the digest
method permits the password file, if stored locally, to utilize
an application-specific or server-specific realm.  The "plain"
keyed-MD5 method doesn't require the realm, but is
(deliberately) defined broadly enough in terms of what happens
on the server host to permit a wide range of alternatives.  Both
methods ultimately require that the secret be stored in a state
that is close enough to clear to make the list of secrets
vunerable if the server is compromised.

Now, again, I'm not particularly attached to CRAM-MD5.  It
served its purpose by providing an implemented and deployed
demonstration that one could avoid the "clear text password over
the network" trap with little marginal overhead in applications
or servers.  If there is community consensus that the digest
approach is better, or that it is time to start migrating to
MD-2005, I'll back that as strongly as I can.   But I do have a
strong preference for standards that will actually be deployed
and used.  To the extent to which the current draft is useful,
we are much more likely to see effective deployment if we keep
the number of changes required in clients and servers to the
minimum number needed to carry out the intent of the spec.   In
the case of a spec like this one, which is intended to improve
the security and reliability of the email environment as seen by
the user, the question "will this make things better" is at
least as important as "will this make things ideal or provide a
perfect solution".   

To that end, since CRAM-MD5 is very widely deployed, I'd like to
see a much stronger justification for removing it than matters
of taste.

On the other hand, if your and your colleagues have concluded
that CRAM-MD5 is inherently dangerous or harmful, I think it is
about time we see an RFC that documents that reasons for that
conclusion, approved through a community consensus process, and
containing recommendations for phasing CRAM-MD5 out, just as the
IETF has previously recommended phasing out clear text passwords.

regards,
    john

---

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Jun 2005 00:51:56 +0300 (EEST)

> What we have learned and what we are able to reach consensus on are two very

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:
>
> 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?

> 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 
[email-masked] 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).

> But both are discussed within the context of messages being sent between

Maybe we agree then that the document actually talks about more than 
just mail submission? (and the title is not accurate)

> 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.

> That's not what it says at all - the "because" is entirely your own 

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..

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 09 Jun 2005 00:10:49 +0200

> see a much stronger justification for removing it than matters

Seconded.

In the programs I use, mostly centered around e-mail and SMTP/IMAP,
CRAM-MD5 is the normal non-plaintext mechanism.  DIGEST-MD5 is rarely
available.

I believe document quality would be served better by mentioning both
CRAM-MD5 and DIGEST-MD5; that the former is currently more widely
implemented; that the latter considered by some to be better; and that
both of them are better than plaintext passwords.

> IETF has previously recommended phasing out clear text passwords.

Seconded!  Personally, I prefer CRAM-MD5 over DIGEST-MD5 in typical
e-mail scenarios.  If you need a security layer, I recommend TLS
rather than the non-interoperable, under-specified, and poorly
analyzed DIGEST-MD5 security layer.  Further, CRAM-MD5 is based on
HMAC-MD5, a cryptographic primitive that at least some real
cryptographers have opinions on.  The keyed-MD5 scheme used in
DIGEST-MD5 is not a standard cryptographic primitive, as far as I
know.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Jun 2005 18:52:33 -0400

Hi.  I'm not in a good position to write a long response now; let me
know if you do end up wanting a longer response and you'll get it in a
week or so.

I don't think cram-md5 is a reasonable best current practice.  I think
it is accurate to describe it as a common practice.  

It's my recollection that cram-md5 is vulnerable to man-in-the-middle
attacks but digest-md5 is not.  It's also my recollection that
digest-md5 will do a much better job of supporting servers that do not
want to store plaintext equivalents than cram-md5.  The server will
store a secret that is sufficient to log into that server but may not
be sufficient to log into other servers.

Digest-md5 also supports an integrity and confidentiality layer.

I think all of the above are significant advantages over cram-md5.

If you are concerned that digest-md5 is not sufficiently widely
implemented then let's recommend plain+tls and digest-md5.  I think
those are two low-infrastructure protocols in wide use.

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Jun 2005 16:01:52 -0700 (PDT)

> intentionally very generic and vague seems much less useful.

And my point is that a less generic document we cannot reach consensus on
is and which therefore cannot be published of no use at all to anyone.

> It may be difficult to get to a consensus what the BCP should be, but

My understanding is that a very large amount of effort and time was needed to
get this far. You are now proposing that even more effort and time be expended
in hopes that consensus can be driven a bit further in a few cases.

Sorry, I don't think it is worth it.

> So, one could at least describe the non-existence of such best

Of course you could. The question is whether it is worth delaying this
specification in order to capture a group of such practices, none of which are
going to be recommended practices.

> [email-masked] accounts which will be used for final delivery.

That ambiguity is intentional, given that there are plenty of cases where it
isn't practical for backup MXes to know all the valid accounts.

> unambiguous enough, careful wordsmithing and clarification appears

Then please provide those clarifications. It looks to me like you're still
wanting to see the backup MX issue addressed at a level of specificity there is
no concensus for.

> how to do this w/ sendmail for example, I'd appreciate an example

Sorry, I don't do sendmail config, but a google search turned up plenty of
pages discussing how to do it in sendmail. It's essentially a one line addition
in PMDF, JESMS, Postfix, and exim. (A rewrite rule addition in PMDF or JESMS,
an addition to the relay domains list in Postfix and exim.) I'm pretty sure its
easy to do in qmail, but I didn't bother to check the specifics.

> just mail submission? (and the title is not accurate)

I guess I could live with "Email transfer" or something similar.

				Ned

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Jun 2005 08:30:56 -0400

Ned Freed <[email-masked]> wrote:
> [Pekka Savola <[email-masked]> wrote:]
>>> [Pekka Savola <[email-masked]> wrote:]
>>>
>>> What we have learned and what we are able to reach consensus on are two 
>>> very different things.

   I submit they are not different after all: where we are unable to reach
consensus, there's a _strong_ indication that not all of us have learned
the lesson yet.

   There _are_ genuine areas of difficulty in reaching consensus, alas.
These need to be explored...

> is and which therefore cannot be published of no use at all to anyone.

   And here we have the war of the generations. :^(

   (I call it the war of the generations because the _typical_ youngster
believes the world can be conquered before breakfast, while the _typical_
oldster has failed to conquer the world so often as to have given up
trying. In point of fact, though, I'm a definite oldster but I'm on Pekka's
side here.)

   We could easily lather, rinse, and repeat those two statements, getting
nowhere. Or we could easily have Pekka make specific suggestions, each of
which could be shot down by some weird case; and lather, rinse, repeat...

   Stepping back a bit, we note that Pekka is standing on grounds of
vagueness -- the sands shifting so fast as to obscure our sight -- while
Ned is standing on grounds of Catch-22 -- daring us to try to find a
consensus that he (or his friends) can't torpedo.

   We need to find common grounds on which to argue this, or we're doomed
to "lather, rinse, repeat". :^(

   When I was younger, I liked to propose where to find the common grounds;
I was even pretty decent at making successful suggestions. But I'm not
young anymore: so until one or the other shows some interest in finding
common grounds, I'm content to watch from the sidelines.

   However...

   There's an issue for all of us here: we are evolving into a paradigm
where the IESG can't agree to form a Working Group to tackle a known
problem (this is particularly obvious where spam is concerned); so they
wait for individual submissions; the individual submissions provoke
controversy; the controversy gets aired a bit on the IETF general list;
no consensus ensues; and eventually the IESG agrees that consensus will
never be reached, so it's better to publish what we have.

   This has obvious implications for the quality of documents approved by
the IESG. The implications are perhaps less obvious on the quality of
people _willing_ to serve on the IESG. (I'm still completely amazed that
Brian agreed to do so!)

   My point is that "Consensus will never be reached!" is a self-fulfilling
prophesy if we never even try the methods we have evolved for doing so.
These include:

 - forming a group which includes enough folks interested in a solution;
 - designating a moderator empowered to redirect efforts towards a goal;
 - designating a document editor to propose language;
 - issuing consensus calls on pieces of the solution;
 - exposing the consensus to review by non-participants;
 - et cetera...

   I've seen a lot of stuff on this list claiming that the IESG has only
itself to blame if its workload increases, because it was foolish enough
to create too many Working Groups. I've been biting my tongue, trying to
avoid shouting, "TANSSATMWG!" (There ain't no such thing as too many
Working Groups.)

   I know a lot of folks disagree with me there: that the "primary" job
of the IESG is managing Working Groups, so there must be some limit to
how many they can manage. I would respond that the IETF seems tolerant
of most any management scheme the IESG may choose; so there's no reason
they couldn't manage thousands of Working Groups. This would, I admit,
require some changes in paradigms:

 - Working Groups would not automatically deserve a session at meetings;
 - dissolution would be automatic with some level of inactivity;
 - Area Directors would not necessarily follow every mailing-list;
 - (I could continue, but you get the idea...)

   I must question whether the IESG sees management of Working Groups as
its primary goal: I think there's increasing evidence that they see
Quality-Control of RFCs as their primary goal, and that they have become
as suspicious of the quality of Working-Group drafts as they are of
individual submissions.

   If so, this is sad, and I wish we could change it.

--
John Leslie <[email-masked]>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Jun 2005 06:36:51 -0700

My personal view (e.g., SASL chair hat off) is that CRAM-MD5
use on the Internet should be limited.  It fails to provide
any form of data security itself.  The lack of integrity
protection means sessions are subject to hijacking.  While
this inadequacy can be addressed by protecting the session
with TLS, if TLS is used then it becomes a real toss-up
between CRAM-MD5 and PLAIN.  While CRAM-MD5 might be viewed
by some as better, I note that PLAIN provides for better
interoperability in systems involving external password
stores (especially in face of string preparation requirements
to be added in revisions of PLAIN and CRAM-MD5 specifications),
and provides support for proxy authorization (identity
assumption).

It is my recommendation that the mandatory-to-implement
"strong" authentication mechanism for this protocol be either:
        DIGEST-MD5 (with a mandate that implementations
                support its data security layers)
        TLS+PLAIN (with a recommendation that PLAIN not
                be used when TLS is not in use).

I have slight preference for the latter.

Kurt

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jun 2005 14:42:14 -0400

Kurt and Sam,

I hope someone else will pick up this discussion, as I'm not the
right person to lead it.  I would encourage you to read and
react to Simon's comments as a start.  However, let me make a
couple of additional observations:

* CRAM-MD5 was caused because folks in the security area said
"no more clear text passwords" to applications folks, then more
or less stepped away.   Whatever the strengths or weaknesses of
either clear text passwords or CRAM-MD5, it was considered an
advantage at the time that they provided authentication, and
authentication only.  In particular, an authentication-only
model, with no attempt or pretense at privacy or integrity
protection for message content, avoids entanglements with any
national or trans-border restrictions that might exist (or be
imagined) on encryption, law enforcement access to keys, etc.  

Now sometimes that is ok, and sometimes it isn't.  I am often
reminded of a conversation with an MIT senior faculty member
some years ago about exposure of information in a
generally-accessible shared-printer environment.  Her response
to my concern was that, if someone decided to pull her material
off the printer and read it, maybe they would learn something
and that was what she and the Institute were all about.  It all
depends on the circumstances.

* There is a huge difference between telling a user or
implementer, in a Security Considerations section or otherwise,
"hey, CRAM-MD5 just provides authentication and no privacy or
integrity protection, if you need either of those, you need to
use it with something else or use something else entirely" and
saying "we have decided, in our wisdom, that authentication-only
solutions are inadequate for you and should be discouraged".

The claims about man-in-the-middle attacks are another matter.
When the analysis was done in 1996, the conclusion was that such
attacks were not possible unless either the secrets were already
known to the attacker or there was a plausible attack on
HMAC-MD5 itself.  If such attacks are now seen to be plausible,
or if post-authentication session hijacking has become a
dominant concern in practice, it is, as I indicated in my
earlier note, time to document that and to use the documentation
as the basis for explicitly deprecating CRAM-MD5 (or HMAC-MD5
itself if necessary).  Similarly, if there is really consensus
in the IETF community that authentication without message
integrity protection, etc., are useless or worse, then it is
time to document that opinion and the associated consensus and
see if we can start persuading implementers and the marketplace
to move on.  

But, in the presence of a fairly broad installed base and
interoperable implementations, I suggest that far more is needed
that the personal preferences of the two of you, or even the
personal preferences of the entire security community, before it
is reasonable to start recommending against the continued use of
a widely-deployed practice.   IMO, such a recommendation has to
be considered a very serious step, especially when the practice
was started as the consequence of some rather specific IETF
recommendations.   We should consider  "never mind what we said
a decade ago about clear text passwords, protected or not; we
now prefer such passwords when sent through encrypted tunnels to
be preferable to challenge-response models" to be a fairly
serious step in terms of IETF credibility if nothing else and
should not take it unless we have clear documentation and clear
consensus, not just changes in taste.

     john

--On Thursday, 09 June, 2005 06:36 -0700 "Kurt D. Zeilenga"
<[email-masked]> wrote:

>> Hi.  I'm not in a good position to write a long response now;
>> let me know if you do end up wanting a longer response and
>> you'll get it in a week or so.
>> 
>> I don't think cram-md5 is a reasonable best current practice.
>> I think it is accurate to describe it as a common practice.  
>> 
>> It's my recollection that cram-md5 is vulnerable to
>> man-in-the-middle attacks but digest-md5 is not.  It's also
>> my recollection that digest-md5 will do a much better job of
>> supporting servers that do not want to store plaintext
>> equivalents than cram-md5.  The server will store a secret
>> that is sufficient to log into that server but may not be
>> sufficient to log into other servers.
>> 
>> 
>> If you are concerned that digest-md5 is not sufficiently
>> widely implemented then let's recommend plain+tls and
>> digest-md5.  I think those are two low-infrastructure
>> protocols in wide use.
>>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 09 Jun 2005 15:07:50 -0400

In message <[email-masked]>, John C Klensin writes:

>itself if necessary).

The environment has changed a great deal.  I don't know why people 
thought MITM attacks weren't feasible in 1996 -- Joncheray published a 
paper on how to carry them out in 1995 -- but they're now trivial.  
There are off-the-shelf tools -- see, for example, Dug Song's dsniff 
package, and read the man pages for arpspoof, sshmitm, webmitm -- and 
the advent of wireless has created a fertile ground for such things.  
(Think about the "evil twin" wireless attacks.)  Factor in routing 
attacks -- they're happening, too -- and you'll see why I'm concerned.

For the record, I've seen active attacks on ssh and web in the wild, at 
the Usenix Security conference and at the IETF itself.  And those were 
without even looking for them.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2005 17:40:28 -0400

> document said "treat as a submission" it meant exactly that.  

Sam is correct here - the text as written is incorrect, even if it accurately
reflects the authors' intent.  

> into the net or you can post/submit from outside.

This is wrong.  "outside the network" is irrelevant.  What matters is whether
you are authorized to use that MTA to submit messages to recipients not in
the domain(s) for which that MTA is authorized to accept incoming mail.

> needs to cover both ports.

There seems to be some ambiguity between treating an incoming 
message as a submission and using the SUBMISSION protocol.
It seems prudent to clearly distinguish the two.  And since treating
an incoming message as a submission has never been well-defined,
perhaps a different way of describing what an MTA should do when
an unauthenticted sender tries to send to a recipient not in a domain
for which the MTA is authorized to accept incoming mail, would be
appropriate.

bottom line: the spec as written is poorly worded and needs 
significant revision.  I'm sending comments to IESG separately.
(and yes, I found the same problem that Sam did, before I read
his message)

Keith

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Jun 2005 15:24:38 -0700

Keith,

>  Sam is correct here - the text as written is incorrect, even if it
>  accurately reflects the authors' intent.

You mean that you disagree with the authors' intent.  That is quite different
from the document being "incorrect".  

The document says what we meant, including the implications.  If there is a
factual error -- and that is what "incorrect" means -- then please state it.

> >  In other words, if you are coming from outside the network, you do not
> >  get to "relay" through the network.  You can post/submit from within,
> >  you can deliver into the net or you can post/submit from outside.
> >
>  This is wrong.  "outside the network" is irrelevant.  What matters is
>  whether you are authorized to use that MTA to submit messages to
>  recipients not in the domain(s) for which that MTA is authorized to accept
>  incoming mail.

I gave a case analysis for 3 conditions.  I believe none of them was wrong and
that there is not a fourth case.  If you feel otherwise, please provide detail.

Again, I believe you are confusing what your own views and preferences are, with
some sort of independent, objective reality.  

"Outside the network" is exactly what we felt was relevant.  It might be dandy
to phrase this as some more generic issue, but since this is an operations
document, for consumption by operations people, it is phrased in a way that is
useful to THEIR perspective.

> >  of the posting traffic on the Internet.  From a practical standpoint,
> >  port 25 is still heavily used; so that the two types of traffic are
> >  still frequently multiplexed over 25.  Hence any BCP concerning initial
> >  posting needs to cover both ports.
> >

Well, I don't see the ambiguity, but I do see the confusion.

Submission is a hand-off from the From/Sender user realm to the mail handling
service.  SUBMISSION is a particular port and service for doing submissions.

The document uses the term 'submission' to refer to the hand-off step.  It quite
carefully distinguishes between the two ports through which submission is
currently done.

If you see any ambiguity, please explain where and what.

>  an incoming message as a submission has never been well-defined,

the term "incoming" is what causes the problem here.  For every server, every
message that it receives is "incoming".  that is true for msa's as well as mtas.

however i suspect what you mean, here, is 'coming from outside the network'.  
since you earlier said that it is irrelevant, i'm not sure what your point is,
here.

  d/
  ---
  Dave Crocker

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Jun 2005 00:30:43 +0200

>                 be used when TLS is not in use).

I don't think recommending the DIGEST-MD5 security layers is a good
idea.

The integrity layer is hard coded to be HMAC-MD5, with keys derived
using a home-grown key-derivation function based on MD5.

Of the privacy layers, only des and 3des were mandatory to implement
in RFC 2831, and both ciphers were dropped in RFC 2831bis, presumable
because they were never implemented correctly nor successfully
deployed.

Either situation alone should be enough to avoid recommending its use
for IETF protocols, in my opinion.

I believe the code complexity cost of DIGEST-MD5 generally outweigh
the small advantages that DIGEST-MD5 may have, for the majority of
users.  This is why, in my perception, DIGEST-MD5 hasn't "taken off".
The lack of cryptographic analysis and cryptographic flexibility
doesn't improve the situation.

TLS+PLAIN seem like a fine recommendation, though.

Cheers,
Simon

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Jun 2005 15:45:07 -0700

>  paper on how to carry them out in 1995 -- but they're now trivial.  

There are some meta-problems with this thread.  

(Aside:  John K has raised his own perspective on some of them and I'd 
like to try to raise mine.  I don't see them as conflicting with John's, 
but rather I'd like to treat them as separate just to avoid having to 
worry about synchronization.  If they overlap with his, fine.  If not, 
well, that's fine too.)

This draft BCP touts some basic practices to improve the accountability 
of mail systems that are injecting messages into the global Internet.  
It cites a range of specifics, for performing those practises, notably 
with respect to some security functions.  Mostly, it cites those 
specifics in order to make give body to the higher-level recommendations 
it is making. It does not particularly recommend one over the other, nor 
do I believe it should.    

Notably it does not invent any technologies or practices.  Rather it 
tries to document and recommend some broad operations practices that are 
established and that result in some general improvements in the email 
service.

The line of discussion about a particular algorithm reflects the rather 
unfortunately tendency to have every system-level effort involving 
security get dragged into low-level debates about basic algorithms and 
about the current views of various experts in the security community.

That's no way to run a standards effort.

First, if the algorithm in question is so terrible, surely the large 
number of folks using it would be experiencing some problems by now.  It 
is not as if we are lacking in attackers exploiting easy holes in 
Internet services.  And surely there would have been global alarums 
raised about this algorithm, given its widespread use and it 
weakenesses.

The current reality is that the ops and apps areas get to play a 
guessing game, in the sure and certain knowledge that they will guess 
wrong.  The security community will always find fault with our choices.

Unless and until the security community can provide the applications and 
operations community some common "packages" to use, just as transport, 
network management and routing do, then we are never, ever going to make 
serious progress using meaningful security.

Yes, I know the arguments for why this is difficult.  And yes, I know 
that security folk claim it is impossible because every service is 
unique. 

That's not good enough.

If the security is going to press for use of good security, then it 
needs to provide far more turn-key solutions to those developing 
services.  Simply requiring that every service be developed with 
security expertise and solutions that are unique to the service is a 
model that clearly does not... scale.

Having debates about what is currently in vogue among various experts is 
a fine thing to do... among the experts.  But it is entirely 
inappropriate to have these spontaneous debates in the middle of 
pursuing a document specifying current practises.  

If there is consensus among the security community that particular, 
established practises are no longer viable, then please go through the 
usual IETF processes for documenting community consensus about it.

At that point, it will make sense for the operations and development 
community to adjust what it specifies.

Until then we are stuck with the vagaries of individual opinions and as 
I recall, that's not what the IETF is supposed to be driven by.

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2005 20:25:29 -0400

> That's no way to run a standards effort.

The current document purports to be a candidate for BCP and yet it  
recommends a practice which is clearly no longer appropriate.    In  
light of the information provided it should be obvious that it's not  
acceptable in its current form.  The fix should also be obvious, and  
the resulting document (with other edits as needed for clarity) seems  
quite useful, timely, and appropriate.

This discussion isn' t holding back the document, it's helping  
provide feedback on what kinds of edits are needed to get the  
document approved.  If anything, one of the authors is holding back  
the document.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Jun 2005 17:57:29 -0700

>  recommends a practice which is clearly no longer appropriate.

clearly?

please provide a citation to any sort of official consensus statement that 
establishes this clarity.

an ietf formal publication would be preferred for the obvious reasons, but a 
reasonable substitute would likely suffice.

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2005 22:07:05 -0400

> establishes this clarity.

you seem to be confusing two things - technical quality and community  
consensus.
both are necessary conditions for approving the document.  but they  
are not the same thing.

or to put it another way -
a) it should be clear to you that CRAM-MD5 has known weaknesses that  
would make it
unlikely to be suitable for BCP
b) it should also be clear to you that a BCP candidate that  
recommends CRAM-MD5 is
unlikely to gain consensus

Keith

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Jun 2005 00:15:57 -0400

> you can deliver  into the net or you can post/submit from outside.

This, I think is the crux of the problem.  The statement above appears to 
conflate an IP network with an administrative domain, and assumes that 
something belongs to one if and only if it belongs to the other.

Fortunately, that is not what the text Sam originally objected to actually 

>    to mail submission authorization and validation checks.

Now, connections that come from clients not on my IP network may be from 
authorized submission clients which are outside my "local environment". 
But, they may also come from clients which are part of my local 
environment, but do not happen to be on my local network.  I might decide 
that a particular client fits that category because of its authenticated 
identity, either to SMTP or at some lower layer.

I've tried for the better part of an hour to come up with a scenario in 
which this matters.  In particular, _any_ scenario in which a message 
addressed to a non-local recipient is not either submission or an attack -- 
whether or not the client is part of the "local environment".  I may not 
have as fertile an imagination or as much operational experience as some 
people in this thread, but I've tried really, really hard.  And I've been 
completely unable to do so.

So maybe whether to treat such messages as "submission" or not is not all 
that important, especially if it is reasonable under some circumstances to 
consider a host not on the local IP network to still be part of the "local 
environment"??

However, I do have another concern with this requirement, and frankly I 
can't remember whether it's been brought up or not.  My concern is with the 
phrase "resolves to a destination that is also outside the local 
environment", and how it interacts with things like forwarding.  If the 
CMU.EDU mail exchangers receive a message whose RCPT-TO is [email-masked], 
and LDAP says that mail for that address should be delivered to gmail, does 
that make it an address that resolves to a destination outside the local 
environment?  The document is not clear on this, and I'm very concerned 
that a wrong answer would result in a lot of incorrectly bounced mail...

-- Jeff

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 07:43:27 +0200

Keith Moore wrote:

>> if you are coming from outside the network, you do not get
>> to "relay" through the network.  You can post/submit from
>> within, you can deliver into the net or you can post/submit
>> from outside.

> This is wrong.  "outside the network" is irrelevant.  What
> matters is whether you are authorized to use that MTA to
> submit messages to recipients not in the domain(s) for which
> that MTA is authorized to accept incoming mail.

I read "inside" as "something avoiding SMTP AUTH like RADIUS",
"outside" as "roaming user, SMTP AUTH or SMTP-after-POP", and
the third case is an unknown stranger saying "HELO".

Simply 2476 or 2476bis vs. 2821.  And what you later said,
tricks based on the MAIL FROM, is "enforced submission rights",
that's 6.1 in 2476 or 2476bis.

> I'm sending comments to IESG separately.

They know 2476bis, it was approved some weeks ago.  And the
relevant parts are the same as in RfC 2476 published 1998.

And if they don't like CRAM-MD5 what they'll get is LOGIN or
PLAIN _without_ TLS, sigh.
                            Bye, Frank

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 00:55:27 -0700

>  something belongs to one if and only if it belongs to the other.

If I had said "IP" network you'd have a pretty good case.  However I meant the 
term pretty generically.  As you note, the document text uses different words.  
In fact that language was carefully chosen.  Unfortunately, this thread has 
tended toward generalities and imprecise language and I succumbed.

(By the way, thanks for returning to the source material and considering it 
specifically.)

....
>  identity, either to SMTP or at some lower layer.

If my use of "network" on this thread were meant as something different from 
"local environment" in the draft, then combinatorial concern you are raising 
would indeed need attention.  And I wish I believed that my use of the word were 
the cause of the problem on this thread.

>  consider a host not on the local IP network to still be part of the "local

Here is the entire text of the recommendations in section 3 of the draft:

Best practices are:

    * Operators of MSAs MUST perform authentication during mail submission, 
based on an existing relationship with the submitting entity. This requirement 
applies to all mail submission mechanisms.
    * 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.
    * Mail coming from outside an email operator's local environment, and having 
a RCPT-TO address that resolves to a destination that is also outside the local 
environment, MUST be treated as mail submission, rather than mail relaying. 
Hence it must be subjected to mail submission authorization and validation 
checks.
    * MDAs SHALL NOT accept mail to recipients for which that MDA has no 
arrangement to perform delivery.

If you or anyone else has specific changes they are suggesting, I'm at a loss to 
guess what.

>  that a wrong answer would result in a lot of incorrectly bounced mail...

unless gmail is part of the local environment for the cmu.edu mail 
service, then how could it be interpreted as anything other than 
"outside"?  

the trick is to be careful in deciding when the evaluation is being 
done: it is evaluated at delivery time, not at the time of acceptance 
into the cmu.edu mail service.

And by the way, if folks want to get into this sort of detail about the 
variations in email handling, I ask that they first make sure they are 
familiar with:

 <http://bbiw.net/specifications/draft-crocker-email-arch-04.html>.  

It has gone through extensive development, specifically because these 
kinds of variations turned out to take quite a bit more thought and 
explanation that had originally been obvious.  The community does not 
have consistent, common language and definitions.  Until we do, debates 
about particular variations are sure to continue to get caught in 
unstated assumptions.

  d/
  ---
  Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2005 11:18:06 +0200

Keith Moore wrote:
> both are necessary conditions for approving the document.  but they  are 
> not the same thing.
> 
> b) it should also be clear to you that a BCP candidate that  recommends 
> CRAM-MD5 is

However, a BCP that states something like

   CRAM-MD5 is widely deployed for this purpose  but due to known weaknesses
   [citations] is NOT RECOMMENDED. The RECOMMENDED alternatives are ...

might have a reasonable chance of gaining consensus.

     Brian

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Jun 2005 07:05:46 -0700

>PLAIN _without_ TLS, sigh. 

I disagree with this statement.  Today, many email client
and server supports TLS, and does so independently of what
SASL mechanisms they may or may not support.  I think most
users and administrators will enable that TLS support if a
plain text password mechanism is chosen.  And, if that's
the RECOMMENDED default, I doubt many users and administrators
will disable TLS without some considerations of th
security implications of their choice.

I think the best option for this protocol, given issues
raised by Simon regarding DIGEST-MD5, is TLS+PLAIN.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Jun 2005 13:01:58 -0400

On Friday, June 10, 2005 12:55:27 AM -0700 Dave Crocker <[email-masked]> 
wrote:

> If my use of "network" on this thread were meant as something different
> from  "local environment" in the draft, then combinatorial concern you
> are raising  would indeed need attention.  And I wish I believed that my
> use of the word were  the cause of the problem on this thread.

It was for me.  Reading the earlier messages, it seemed to me that the 
specified behavior was broken.  Then I went back and read the original 
text, and saw that it said "local environment" and nothing about "network", 
and it suddenly didn't seem so broken any more.

> If you or anyone else has specific changes they are suggesting, I'm at a
> loss to  guess what.

I'm not suggesting any change.  I initially had the same concern as Sam, 
that there was a requirement to treat things as submission that really 
weren't.  But given a reasonable interpretation of "local environment" 
(i.e. one that does not assume it always means "local IP network"), I've 
managed to convince myself that there aren't any cases left where it 
matters.  So if the experts don't think this is a problem, then neither do 
I.

> about particular variations are sure to continue to get caught in

Indeed.  The answer to my concern appears to lie in the subtle but 
significant semantic distinction between Relaying and Aliasing, which I 
didn't understand before reading your architecture document.  Having done 
so, I can withdraw my comment on the "resolves to" phrasing, and replace it 
with a different one:

Maybe the spamops document needs a reference to the email-arch document?

-- Jeff

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 10:23:24 -0700

Jeff,

>  significant semantic distinction between Relaying and Aliasing, which I

I went through quite a number of iterations about aliasing in the email-arch 
document, based on lots of feedback.  It does, indeed, seem to be a challenging 
function to place into an architecture.

>  Maybe the spamops document needs a reference to the email-arch document?

I'm going to suggest that to the other authors.  In fact, the architecture 
discussion in the spamops document was the motivation (actually the basis text) 
for the email-arch document.  After we did the spamops early drafts, I decided 
that the community needed something specifically about email architecture.  I 
thought it would be straightforward to write.  That was roughly a year and 3 
major iterations ago...

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2005 14:07:16 -0400

> and it suddenly didn't seem so broken any more.

at the very least it illustrates that using vague terms in a technical specification
without defining those terms can lead to misunderstanding.  fortunately the
misunderstanding was discovered before the document was published, so that
it can be clarified before it does harm.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 12:45:07 -0700

> > >  If my use of "network" on this thread were meant as something
> > >  different from  "local environment" in the draft, ...
> > >
> >  text, and saw that it said "local environment" and nothing about
> >  "network",  and it suddenly didn't seem so broken any more.
> >
>  without defining those terms can lead to misunderstanding.  

Keith, the problem with pushing so hard to win a point, without actually reading
things carefully, is that the material often does not substantiate the point.

What you are so winningly touting was not, as you indicate, a problem with the
text, but a problem with my use of a different term in this thread.

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2005 16:25:58 -0400

> >  at the very least it illustrates that using vague terms in a technical
> >  specification without defining those terms can lead to misunderstanding.  
> 

Dave,

I disagree.  I think this illustrates that you don't have a clear handle on what you
are talking about.

rather than try so hard to deny that the text is ambiguous, why not just fix the text?

Keith

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Jun 2005 16:38:53 -0400

On Friday, June 10, 2005 04:25:58 PM -0400 Keith Moore <[email-masked]> 
wrote:

>> Keith, the problem with pushing so hard to win a point, without actually
>> reading things carefully, is that the material often does not
>> substantiate the point.
>>
>> What you are so winningly touting was not, as you indicate, a problem
>> with the text, but a problem with my use of a different term in this
>> thread.
>
> Dave,
>
> I disagree.  I think this illustrates that you don't have a clear handle
> on what you are talking about.
>

FWIW, I found the actual text perfectly clear; it was indeed the discussion 
that was confusing.  I wouldn't object to further clarification, but I 
don't have text to propose, either.  Do you?

-- Jeff

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2005 16:52:53 -0400

> don't have text to propose, either.  Do you?

It's hard to propose text that says what you mean when I don't know what you
mean (and cannot determine it from the text that is written).

I can certainly propose text that (I believe) says what _I_ think it should say.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2005 16:57:48 -0400

when I should have written:

> It's hard to propose text that says what they mean when I don't know what they

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 23:22:10 +0200

> and server supports TLS

Not my favourite old MUA, unfortunately.  When I implement a
simple script I'm limited to a socket interface, and in that
case cram-md5 / digest-md5 / otp is the best I have.  And the
server in question offers login / plain / cram-md5 for AUTH.

> raised by Simon regarding DIGEST-MD5, is TLS+PLAIN.

Where that's possible it's fine.  I'm more interested in the
case where it's impossible.  My understading of the draft is:

"Whatever you do stay away from PLAIN (or the obsolete LOGIN)
 without TLS, use at least CRAM-MD5".

Maybe Brian's proposed compromise covers this concept somehow.
And he wanted "known weaknesses [citations]".  That's about
today, not about some results of the not yet existing HASH WG
in 2006 or later.
                      Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 23:50:39 +0200

> Maybe the spamops document needs a reference to the 

No, this is still highly controversial.  To put it mildly.
The spamops-document OTOH is fine for practical purposes.

                          Bye, Frank

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2005 22:18:10 -0400

> The spamops-document OTOH is fine for practical purposes.

I agree that putting the arch document in the critical path for  
spamops would be likely to considerably delay publication of  
spamops.  Nor does it really seem to be necessary, as the concepts  
and terms used  by spamops are few enough to define in that document,  
even if they're redefined later in an arch document.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Jun 2005 00:07:38 -0400

> might have a reasonable chance of gaining consensus.

And that is exactly the document that I, and others in the email
community, have been requesting for a few years now.  However,
to be completely precise:

(1) "known weaknesses [citations]"  is significantly different
from "we don't like it" or "we assert it is bad" or even "we
don't like things unless  they contain several additional
layers".  The third of these might be a reasonable statement,
but would require even more justification because...

(2) CRAM-MD5 was designed around a particular market niche and,
based on the number of implementations and how quickly they
appeared, seems to have responded correctly to it.  It may be
appropriate at this point to conclude that market niche has
outlived its usefulness, but if "The RECOMMENDED
alternatives..." include only things that are significantly more
complex or require significantly more infrastructure, there is
some reason to believe that they will go nowhere fast,
independent of any pronouncements the IETF chooses to make.

     john

---

From: "Tom Petch" <[email-masked]>
Date: Sun, 12 Jun 2005 19:26:45 +0200

<inline>
Tom Petch
----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "Keith Moore" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Dave Crocker" <[email-masked]>
Sent: Saturday, June 11, 2005 6:07 AM
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP

<snip>

> independent of any pronouncements the IETF chooses to make.

I am reminded of the following from secsh-architecture, in the context of how to
check the ssh host public key, and so authenticate the ssh host.

" The members of this Working Group believe that 'ease of use' is
   critical to end-user acceptance of security solutions, and no
   improvement in security is gained if the new solutions are not used.
   Thus, providing the option not to check the server host key is
   believed to improve the overall security of the Internet, even though
   it reduces the security of the protocol in configurations where it is
   allowed."

For me, this is sound engineering, imperfect but recognising the frailties of
the world,
producing something that will be deployed.  I apply the same logic to MD5.

---

From: David Hopwood <[email-masked]>
Date: Mon, 13 Jun 2005 01:45:39 +0100

Tom Petch wrote:
> From "John C Klensin" <[email-masked]>:
> 
> the world, producing something that will be deployed. 

I am all in favour of usable security. All too often, however, "ease-of-use"
is used to justify security compromises, without even thinking about how a
higher level of security and a better user interface could be achieved
simultaneously. That is *not* sound engineering.

> I apply the same logic  to MD5.

We know how to design password-based protocols that prevent session hijacking
and dictionary attacks, provide mutual authentication, and do not require
storing password-equivalent authenticators. It is not rocket science,
and it does not require any additional effort from the user. That's not
the problem; the problem is a lack of *concrete* deployable security
protocols that implement the known state of the art.

(TLS prevents session hijacking, but does not implement strong password
authentication. AFAIK, the nearest thing available is
<http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-09.txt>.)

-- 
David Hopwood <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 12:30:06 -0700

>  specification

  d/
  ---
  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 10:07:30 -0700

Folks,

We were asked to fill out a draft form as part of the IETF submission process, 
to provide background about the spamops effort.  

The form seems useful as input to the public discussion, as well as the iesg 
discussions.

A copy is located at:

  <http://mipassoc.org/spamops/request%20for%20BCP%20status.txt> 

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2005 14:25:01 -0400

>   <http://mipassoc.org/spamops/request%20for%20BCP%20status.txt> 

This status file claims that the document in question has had "Multiple
references to the document in the IRTF's ASRG and the retained ietf-
smtp mailing list."  I took the trouble to search my archives of the
ietf-smtp mailing list, and found exactly four mentions of that
document title or ID.

The first two mentions were a question about one particular aspect of
version -00 of that document, and one reply to that specific question.
These were one year ago.

The second two mentions of the spampos document were in a discussion 
of the SPF draft, and didn't actually discuss the spamops document.

While the claim in the status file is true on its face (there really
were multiple "references" to the document) one should not infer that
the document has actually been discussed on the ietf-smtp list, because
no significant discussion or review has taken place there.  In
particular, the ietf-smtp list does not seem to have been explicitly
asked to review the document, even though that is the de facto place to
discuss uses of and extensions to SMTP.

Frankly, it's hard to see this as other than an attempt at an "end run"
around the SMTP developer community.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 11:47:13 -0700

Keith,

>  ietf-smtp mailing list, and found exactly four mentions of that

Multiple:  "Having, relating to, or consisting of more than one individual, 
element, part, or other component; manifold."

Also, the statement carefully said "references" rather than discussion.  So the 
statement makes no more than a minimal, and correct, claim.

>  the document has actually been discussed on the ietf-smtp list, because

indeed.  one usually should not infer more than is said, particularly in a 
formal document.

>  around the SMTP developer community.

Let's see:  it gets announced multiple times on an smtp developer 
community mailing list.  That community chooses not to pursue the 
matter.

Your criteria for "end run" appear to be rather liberal, if not silly.

You wouldn't be trying to delay things, so as to somehow force 
discussion of your now-competing document, would you?

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2005 15:03:06 -0400

> community mailing list.  

"announced" is quite a stretch.

> That community chooses not to pursue the  matter.

Perhaps because it was not invited to do so, or perhaps because (to
those who were aware of the document) it seemed premature to do so.
It's not as if every I-D is worth reviewing, particularly in the early
stages.  A lot of I-Ds are abandoned by their authors without any 
attempt to publish them as RFCs.

> discussion of your now-competing document, would you?

I certainly want to encourage adequate review of whatever gets published
as an RFC.  As for "competing document", well at this stage it's not even an
I-D.  I consider it a contribution to the discussion.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 12:16:32 -0700

>  Perhaps ... or perhaps ...

or perhaps, or perhaps , or perhaps...

> I consider it a contribution to the discussion.

Keith, if you want your postings to have a constructive effect, it would help if
they took a constructive tone and had constructive content, rather than making
essentially slanderous claims about end-runs, and offering hypotheticals for
which there is no basis.

The document had quite a few, independent people contribute to it.  It has gone
through considerable evolution.  These are facts.  The form cites these facts.  
Whether you think there needs to be more discussion and modification is fine,
but don't start looking for silly conspiracies.

The document is being offered to the IETF in the usual manner of an independent
submission, for the usual manner of review and, if necessary, modification.

Rather than nit-pick the form that was submitted or cast aspersions on our
motives, why not focus your considerable talents on constructive dialogue?

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2005 16:02:13 -0400

> essentially slanderous claims about end-runs, and offering hypotheticals for 

Dave,  you don't have a leg to stand on here.

If you want to fix your document, I'm all for it, and I believe that is the quickest
path to getting a useful document out the door.  But I will insist that it be fixed
and that the fixes get adequate review.  

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 13:18:44 -0700

>  Dave,  you don't have a leg to stand on here.

boy, it's a good think i'm sitting.

>  But I will insist that it be fixed and that the fixes get adequate review.
>

i apologize.  i did not realize that you had a personal veto.  i always thought
that the ietf requirement was to obtain support from others for one's views.

  d/
  ---
  Dave Crocker

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2005 16:24:54 -0400

> i apologize.  i did not realize that you had a personal veto. 

and I didn't realize that you had personal authority to expect that your
documents be published as IETF consensus documents without adequate 
review.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 13:33:24 -0700

>  documents be published as IETF consensus documents without adequate

indeed.  so it's probably a good thing that i said nothing to indicate that.

oh...

> The document is being offered to the IETF in the usual
> manner of an independent submission, for the usual manner
> of review and, if necessary, modification.

How about that.  I seem to have said exactly the opposite of what you
attribute to me.

but hey, thanks for continuing down such a constructive path.  we
wouldn't want to get bogged down in nit-picking attacks.

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2005 16:35:59 -0400

Dave,

If I'm not mistaken, the ball is in IESG's court now.  As far as I can tell, they have
enough input to know what to do.   

Keith

---

From: April Marine <[email-masked]>
Date: Tue, 14 Jun 2005 13:37:55 -0700 (PDT)

guys? do ya mind? take a breath

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 12:13:02 -0700

d/
  ---
  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 13:11:22 -0700

d/
  ---
  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jun 2005 13:32:47 -0700

oh...

  d/
  ---
  Dave Crocker

---

From: Dean Anderson <[email-masked]>
Date: Wed, 15 Jun 2005 16:45:12 -0400 (EDT)

There is a tremendous amount of myth propogated in this document.

The notion that email authentication has helped reduce spam is completely
unsubstantiated by actual practice. We have just recently observed the
failure of SPF, largely due to the fact it didn't work.  Email
authentication, even if possible by some other method, doesn't solve the
problem, since it is the equivalent of dialup problem:

        Every user is authorized to send email until they aren't. 

        Only their service provider can remove that authorization

And of course, it isn't just users who send email. Devices send email, 
too.

Service providers aren't complaining that they can't identify they users.  
Rather, the people frustrated by email authentication are the end user
recipients of spam. Email authentication isn't going to lessen that. Even
if it were do-able (and done), end-users and other carriers wouldn't have
access to the subscriber identity information.  And if they are your
subscriber, you usually don't have any lack of identity information given
a spam and its headers.

Service providers implementing protocols like SMTP-AUTH have not reported
that SMTP-AUTH results in less spam.  Just the opposite is usually the
case: No change.  

Email authentication isn't a weakness that is exploited by spammers.  
commercial bulk emailers are by and large compliant with the CAN-SPAM act.  
The CAN-SPAM Act has demonstrated a distinction between commercial bulk
emailers and abusers with no direct commercial purpose. (see
http://www.av8.net/SpamTypes.txt).  Abusers have been using viruses and
rooted computers to send abuse email. It is not the economics of
commercial bulk email, nor the lack of email authentication that is the
problem. It is the economics of anti-spam blacklists that shows that
"economic value" of virus/abuse "spam".  Blacklists such as SORBS are now
charging (extorting) money from both users and victims.

And lastly, it seems inappropriate that such a draft would be proposed
with language about open relays without seeking the input of open relay
operators such as Av8 Internet. Av8 Internet is one of the very few open
relay operators that is willing to publicly discuss these operations.  
Av8 has operated open relays since 1996 and has considerable experience
with abusers and the methods of protecting open relays from abuse. While
groups like Nanog have worked to suppress certain viewpoints
(http://www.iadl.org/nanog/nanog-story.html -- this page is not yet
finished, but I've made an early version available) it is still well-known
that I am willing to discuss the issues and have a lot of research to
support my views.

Had anyone bothered to ask, I would have reported that open relay abuse
has dropped off to nearly nothing since the open relay blacklists shutdown
in 2003. Previous testing of open relay blacklists had revealed that they
were involved in directly or indirectly supporting abuse, promoting abuse,
and even soliciting the abuse of open relays. Logs revealed that these
blacklists were the only groups systematically searching for open relays
to abuse, and that open relays were only abused after discovery by the 
open relay blacklists. 

I do note that open relay abuse has resumed slightly since SORBS.NET
started scanning for open relays in March 2005, but there are presently
only about 5 IP addressses abusing our relays, despite the well-known fact
that we operate open relays. In the past, we would sometimes see as many
as 2400 IP addresses trying to abuse our relays.  Nearly all of this abuse
is fairly trivially detected and blocked. Open relays do not present any
"problem" to be addressed.

I think the IETF should make more efforts to make sure that its
recommended best common practices are based on facts rather than myths.

Dean Anderson
Av8 Internet, Inc

=====================================================================

   Best practices are:

   o  Operators of MSAs MUST perform authentication during mail
      submission, based on an existing relationship with the submitting
      entity.  This requirement applies to all mail submission
      mechanisms.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Jun 2005 00:32:56 +0100

On Wed, 15 Jun 2005, Dean Anderson wrote:
> in 2003.

MXs are routinely probed by relay attempts: we see about 2000-4000 such
attacks each day. A similar volume of relay attempts occurs for machines
named 'mail' or 'smtp'. More obscure mail hosts might see a more
manageable number of attacks, but I still think it is valid for this draft
to state that it is best practice that MTAs must not be configured for
open relaying.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Jun 2005 17:28:37 -0700

>  unsubstantiated by actual practice.

Which bit of text in the document are your referring to?

>  Email authentication isn't a weakness that is exploited by spammers.

But the lack of accountability for message senders IS.

>  relay operators that is willing to publicly discuss these operations.

There is a strong rough consensus in the email operations community that open 
relays -- MTAs that accept mail from any source on the open Internet, when it is 
directly destined to go back out to the Internet -- prevents providing 
reasonable levels of message sender accountability.  

That rough consensus has been in place for quite a few years.

>  Had anyone bothered to ask, I would have reported that open relay abuse

The fact that attackers are not trying to exploit a particular weakness right 
now, although they used it heavily in the past, does not justify leaving the 
weakness in place.

  d/
  ---
  Dave Crocker

---

From: Dean Anderson <[email-masked]>
Date: Wed, 15 Jun 2005 20:50:44 -0400 (EDT)

I don't see that sort of probing on our MXs, except on rare occasions, and 
we haven't seen it recently.

What sort of mail volume to you handle?  2000-4000 attempts isn't a lot 
for large volume domain handling millions of messages per day.

You said it is more prevalent on hosts named mail or smtp---one would at
minumum need a list of domains to search. Where do you suppose they
obtained this list?  Do you have a particularly well-known domain?

Who is doing this searching?  Internal viruses?  Perhaps your should
report it to the organizations doing the probing.

What sort of commercial companies are abusing your open relays?  We
haven't found any commercial advertising in open relay abuse in the 9
years that we've run open relays.

People should and do use open relay when it is necessary: When you have to
provide email services to persons and organizations outside your address
space.

You also haven't shown that the abusers would be prevented from emailing
if open relays were closed.  There are number of myths about open relays
that are debunked in http://www.av8.net/FTC.pdf which was submitted to the
FTC spamforum in 2003, after the FTC issued a press release against open
relays. The FTC didn't permit participation by open relay operators, and
an FTC lawyer supervising the forum even ridiculed John Gilmore.  
However, the FTC did allow known spammer Scott Richter to attend. It was
later learned that MAPS employees were working for Richter.  And the FTC
did use a blacklist called Osirusoft run by Joe Jared. Among other revenge
activity, Jared blacklisted his ex-girlfriend out of spite after the
relationship failed.  In spite of this incident, the FTC continued to use
the blacklist until it shutdown later in 2003, blacklisting the entire
world, and disrupting the email of all the blacklist subscribers,
including the FTC.

Part of the fallacy embodied in the open relay myth and also in the email
authentication jihad is that:

	Every user has relay services until they are no longer a user. 

That includes viruses and spammers.  So why should it be anti-spam "best
practice" not to use open relays?  Open relays have nothing to do with
spam. They never have.

		--Dean

---

From: Ned Freed <[email-masked]>
Date: Wed, 15 Jun 2005 18:02:38 -0700 (PDT)

> we haven't seen it recently.

FWIW, my logs on mrochek.com (my home domain) show around 35,000 relay attempts
during the past 6 months. This number is almost certainly much too low, in that
I have various other blocks in place that may stop relay attempts before they
get to the "don't allow relaying" rule.

A cursory examination of the logs shows that most of the destination addresses
are ones I've never heard of. But there are also a fair number of addresses I
recognize as IETF people. Sure looks like somebody is tracking sender-recipient
pairs off of mailing list mail.

Mrochek.com probably qualifies as an obscure domain.

> for large volume domain handling millions of messages per day.

Overall traffic is about 500 legit messages a day and a highly variable amount
of spam, but rarely less than a thousand spams and viruses a day.

I don't think I'll be making my home system an open relay any time soon...

				Ned

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Jun 2005 08:49:01 -0400

> That rough consensus has been in place for quite a few years.

sometimes rough consensus is wrong, particularly when it hasn't resulted 
from informed, intelligent dialogue.  another way to put it is that 
sometimes rough consensus is indistinguishable from blind prejudice.

it's possible to have open relays that don't contribute to spam.  but 
those relays need to employ some other means, e.g. rate limiting, to 
block spam.  the goal of such relays is to make it at least as easy for 
the spammer to simply contact the appropriate MXes for the destination 
addresses as to use the relays.  of course it is necessary for such 
relays to record source IP addresses, etc., so that they are as 
traceable to their origin as messages sent directly to MXes.

unfortunately, the vigilante character of various open-relay blacklists 
killed any attempt at this kind of innovation.  just as we're now in 
danger of various kinds of brain-dead "authentication" methods and 
meaningless requirements killing useful email functionality.

> now, although they used it heavily in the past, does not justify leaving the 

this much is certainly true.

Keith

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Jun 2005 15:48:31 +0100

> for large volume domain handling millions of messages per day.

About 250K legit messages each day, and about a million junk messages.
Yes, it isn't a very large proportion of our total volume, but I would
expect that to change rapidly if the probes were successful.

> obtained this list?

Where do you suppose they get lists of email addresses to send spam to?

> Who is doing this searching?  Internal viruses?

The probes are external, and appear to be mostly from compromised home
computers. Our network is reasonably well managed and infections are
quashed promptly.

> What sort of commercial companies are abusing your open relays?

You misunderstand: We don't operate open relays, but despite your claims
about the rareness of open relay abuse, our email servers are frequently
probed with open relay attacks. I believe you are depending on security
through obscurity to avoid attack. One of our main outgoing relay services
has an obscure name (ppsw.cam.ac.uk) and is probed 100 times less
frequently than our MXs or our MSA service named smtp.hermes.cam.ac.uk.

> if open relays were closed.

That's irrelevant: it's still my responsibility not to abet them.

Tony.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Jun 2005 08:45:52 -0700

Keith,

>  those relays need to employ some other means, e.g. rate limiting, to

Rate limiting is a relatively recent technique.  Though very useful it has... 
ummm, limited applicability.  

One needs to be careful not to dismiss established techniques in favor of the 
latest fashionable one that is not as well fully understood.

For example, rate limiting is used to control a single source. It's quite useful 
when used at the destination. At a sufficiently well-run source network, it also 
can be pretty useful.

The problem is with zombies.  They make mush of old-time models of spam, since 
they demonstrate that a very small data stream from a single source can be 
leveraged into a very, very large data stream, given enough sources. 

One can start imagining more complex rate-limiting models, but then we would be 
talking about research efforts.  A BCP is not supposed to rely on research, 
especially when it hasn't been done.  

Besides that, note my comment above about "sufficiently well-run source network" 
is clearly not possible when the network accepts mail without accountability of 
the submitter.  In other words, an open relay.

>  traceable to their origin as messages sent directly to MXes.

I don't know how much experience you have trying to do such tracing, but the 
spamops folks have made quite clear that it is both vastly more effort and 
considerably less productive, than one might expect.  Again, there is no way 
that relying on that is a reasonable best practise on the current Internet.  As 
a small example, not that spammers now are stealing IP Address blocks.  That 
pretty much kills backtrace accountability.

>  unfortunately, the vigilante character of various open-relay blacklists

blacklists are not the subject of this BCP.

>  meaningless requirements killing useful email functionality.

new authentication methods are not the subject of this BCP.

  d/
  ---
  Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Thu, 16 Jun 2005 09:06:04 -0700 (PDT)

> ummm, limited applicability.

Actually, in my neck of the woods at least rate limiting has been a popular
technique to use for at least five years, and has been in use at some sites for
a lot longer. However, I see it used mostly in two ways:

(1) To limit the amount of damage a local zombie can do.
(2) To limit incoming spam.

I've been tempted to try and write a document about rate limiting, but the
problem is most of the information I have about its effectiveness (or lack
thereof) is anecdotal in nature. Such a document really needs to be developed
by folks with substantial experience using the technique on a large site over a
number of years, and even then I don't think you're going to get an analysis of
its relevance to operating open relays.

> latest fashionable one that is not as well fully understood.

The problem with rate limiting isn't that it isn't well understood, for some
class of attacks at least. Rather, the problem is, as you indicate below, the
nature of the threat continues to evolve, and the way it has evolved has made
rate limiting less useful, for sure when it comes to blocking incoming spam. It
remains useful in limiting damage from local zombies, mostly because these
still tend to send lots of messages very quickly.

> when used at the destination. At a sufficiently well-run source network, it also

Exactly.

> leveraged into a very, very large data stream, given enough sources.

Zombies are indeed the problem, but it breaks down into two cases, one where
the zombies you're trying to deal with are your own systems (or your customer's
systems), and another where the zombies are elsewhere and are targetting you.
Rate control, especially rare control with notification, is still pretty
effective at dealing with local zombies.

However, I fear that use of rate limiting to allow open relaying is more
cloesely aligned with the second case.

> especially when it hasn't been done.

The rate limit stuff I see in use is an odd mixture of sophistication and
simplicity. For example, it is common to see limits applied at multiple levels,
that is, there may be a limit on recipients per transaction, a limit on
transaction per session, and finally a rate limit on incoming sessions.

However, it is often the case that rate limit information isn't shared all that
well between mutlple systems. I also don't see careful analysis of the effect
of rate limits being done, although that may be more due  to folks keeping
their results to themselves than anything else.

> the submitter.  In other words, an open relay.

Agreed.

> pretty much kills backtrace accountability.

This is another case where I have only anecdotal information - I may write the
software but I don't run a large site that uses it - but the information I have
agrees with your assessment.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Jun 2005 14:21:27 -0400

> ummm, limited applicability.  

mostly because of blacklists.  it was working fine for its intended purpose.

> latest fashionable one that is not as well fully understood.

I don't know what you mean by "relatively recent", but I was doing it at least
as early as April 1999 - that's the last mod date on my source files.  RFC 2554
only dates from March 1999.

> when used at the destination. At a sufficiently well-run source network, it also 

It's also pretty useful for preventing a relay from being exploited by spammers.
 
> leveraged into a very, very large data stream, given enough sources. 

Rate limiting of this type (based on source IP address), if done properly, doesn't 
help or hurt zombies.  The rates need to be set such that zombies can send directly
to the recipients' MXes as easily, and more reliably, as they can send the same 
mail via the rate limiting SMTP servers.

> especially when it hasn't been done.  

Maybe you should stick to talking about things that you know something about.

> considerably less productive, than one might expect. 

That's a problem with mail relaying in general, not just with open relays.
Now if you want to discourage multi-hop mail relaying, that might actually be
useful for lots of reasons besides just traceability.

> blacklists are not the subject of this BCP.

This thread has pretty much diverged from the subject of your draft
document anyway.

> new authentication methods are not the subject of this BCP.

You mean "your draft document".  It's certainly not a BCP as it's 
currently written.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Jun 2005 11:29:18 -0700

>  Maybe you should stick to talking about things that you know something

I thought that ad hominem attacks were considered unacceptable on this list?

  d/
  ---
  Dave Crocker

---

From: Dean Anderson <[email-masked]>
Date: Thu, 16 Jun 2005 15:56:57 -0400 (EDT)

> expect that to change rapidly if the probes were successful.

Yes, indeed. It will change if the probes are successful. But it is easy
figure out who is doing the probes. Open relay probing requires an valid
emailbox. So just queue up the probes, identify the blacklist (its usually
something like relaytest@<blacklist>). In the rare case it is not plainly
a blacklist, send in an abuse report on the destination emailbox.

Another technique is to run non-production open relays, let them be
scannned, and see what blacklists the relays turn up on, and then start
blocking (and reporting) any IPs that try to connect to the non-production
relays.  

Anti-spammers also scan the /24 around any known open relay before abuse.
This behavior started shortly after I reported that I could identify abuse
with the specific blacklist that was promoting the abuse. I did this by
adding different non-production relays to different blacklists, and then
tracking the IPs and spams that came through.  After that, they started to
scan the /24 immediately before abuse to obscure which blacklist was doing
the abuse.  If you have enough address space, you can still conduct the
tests with each relay on a different /24. After that, they started
claiming that 130.105/16 was stolen.

> Where do you suppose they get lists of email addresses to send spam to?

That's not the same thing. Most of those lists have AOL and MSN and the
top 50 or 100 or so domains. I have the spam email lists, too. The email
addresses show up in my logs and the block email messages' envelope
recipient lines [RP.*FD in sendmail]. That doesn't give them enough to
find very many open relays by simply adding mail or smtp to the domain
names from a list of email addresses.

Open relay abuse just doesn't scale. Too much searching, too few relays.

> frequently than our MXs or our MSA service named smtp.hermes.cam.ac.uk.

Well, script kiddies may do many odd things. Further, if you aren't
running open relays, how do you know for certain that it's not just
misconfigured clients?  "Relaying denied" is a frequent problem
experienced by real customers who aren't spammers.

Adding mail or smtp to a domain is probably something your legitimate
users are doing, trying to figure out how to relay remotely. Very likely,
this represents the number of legitimate mails your users would like to
'open relay.'

> That's irrelevant: it's still my responsibility not to abet them.

I'm not "abetting" them.  They send email no matter what. They didn't get
anything they don't already have.  And in practice, its the anti-spammers
who are abusing open relays (to teach us a lesson), not real bulk
commercial emailers.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 16 Jun 2005 16:16:41 -0400 (EDT)

> ummm, limited applicability.

I tried a "rate limiting" freeware a couple years ago. It didnt' work,
largely due to very poor programming. It had no locking. The programmers
didn't seem to understand that the program could be invoked
simultaneously. It worked only so long as there was only one message at a
time, a rate so slow as to not require rate limiting.

But abusers do look and behave differently from regular users.  This can
be exploited to some extent.  Slow queues that wait for an abuse pattern,
and so forth.  But the best thing is to just block the blacklists from 
scanning. And the techniques I just described to Tony Finch.

> leveraged into a very, very large data stream, given enough sources.

It is interesting that the most recent "email authentication" scheme (SPF)
asists the zombies by identifying the ISP's (possibly closed) outgoing
relays. If the ISP happens to block port 25, which may be attractive to
residential ISPs which also happen to have the most zombies, then the
zombie needs to use the ISPs relays.  Finding that relay for a thousand
different mail clients is a chore, and would have to be performed by a
severely limited virus payload. But along comes SPF, and identifies those
relays for the zombie.  Foot, gun, trigger. Or perhaps SPF was more
intentional, and also happened to be a great source of money.

> pretty much kills backtrace accountability.

The spamops folks are frequently unreasonable in this respect. They have
asserted, for example, that one cannot trust _any_ mail headers.  They
expect _immediate_ results. Those are just unreasonable demands.  No ISP
is going to cancel a users account on the say-so of some unreasonable
anti-spammer, who (as a group) are already well-known for outright lying,
revenge, and defamation.

Tracking a spam zombie requires a bit of patience and persistence. There
is nothing that will make that easier, except perhaps a standard abuse
submission protocol (which I proposed back in 1999).

> blacklists are not the subject of this BCP.

Its couched in terms to avoid that, and just assumes the blacklists claims
about open relays are right.

> new authentication methods are not the subject of this BCP.

It doesn't specify a specific method. It just says that email
authetication should be used.

		--Dean

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jun 2005 14:52:30 +0200

> I thought that ad hominem attacks were considered unacceptable on this list?

On any IETF list, actually. It's best all round if people remain
professional and polite, however strong the disagreement.

    Brian

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 20 Jun 2005 13:46:41 -0400

On Fri June 3 2005 09:47, The IESG wrote:
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-07-01.

Comments:

Internet-Drafts and RFCs are required to meet certain criteria:
[R1.Checklist] (see also references in that document), [R2.ID],
[R3.Instruct].  These can be checked by using the "idnits" tool:
[R4.idnits].  That tool noted the following regarding the document:

  idnits 1.73 (17 Jun 2005)

  draft-hutzler-spamops-04.txt:

    Checking nits according to
    http://www.ietf.org/ID-Checklist.html:
    * The document seems to lack an IANA Considerations section.
      Checking conformance with RFC 3978/3979 boilerplate...
    * The document seems to lack an RFC 3978 Section 5.1 IPR
      Disclosure Acknowledgement.

    (Expected a match on the following text:
      "By submitting this Internet-Draft, each author represents that
      any applicable patent or other IPR claims of which he or she is
      aware have been or will be disclosed, and any of which he or she
      becomes aware will be disclosed, in accordance with Section 6 of
      BCP 79.")

      (The document uses RFC 3667 boilerplate or RFC 3978-like
      boilerplate instead of verbatim RFC 3978 boilerplate.  After 6
      May 2005, submission of drafts without verbatim RFC 3978
      boilerplate is not accepted.)

    Checking nits according to
    http://www.ietf.org/ietf/1id-guidelines.txt:
      Nothing found here (but these checks do not cover all of
      1id-guidelines.txt yet).

    Miscellaneous warnings:
      None.

The wording of the document is poor.  [R5.editor62] may be useful.  Many
terms (details below) are undefined, poorly defined, or inconsistently
defined.  Many "sentences" suffer from odd placement of punctuation,
particularly commas, which make parsing those "sentences" impossible.

The (intended) status of the document is:

   [ ] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [X] Best Current Practice

   However, the status as defined in [R6.BCP9] should be:

   [ ] Experimental (typically denotes a specification that is part of
       some research or development effort, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [X] Informational (published for the general information of the
       Internet community, does not represent an Internet community
       consensus or recommendation, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
       choices, is believed to be well-understood, has received
       significant community review, appears to enjoy enough community
       interest to be considered valuable, has no known technical
       omissions)

   [ ] Draft Standard (at least two independent and fully interoperable
       implementations from different code bases have been developed,
       sufficient successful operational experience has been obtained,
       unused options and features have been removed, well-understood,
       known to be quite stable both in its semantics and as a basis for
       developing an implementation, must have been Proposed Standard
       for at least six months)

   [ ] Internet Standard (significant implementation and successful
       operational experience has been obtained, characterized by a high
       degree of technical maturity and by a generally held belief that
       the specified protocol or service provides significant benefit to
       the Internet community, must have been Draft Standard for at
       least four months)

   [ ] Historic (A specification that has been superseded by a more
       recent specification or is for any other reason considered to be
       obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
       results of community deliberations, subject to the same basic set
       of procedures as standards track documents, the community's best
       current thinking on a statement of principle or on what is
       believed to be the best way to perform some operations or IETF
       process function, common guidelines for policies and operations
       which are generally different in scope and style from protocol
       standards, not well suited to the phased roll-in nature of the
       three stage standards track and instead generally only make sense
       for full and immediate instantiation)

   [ ] None of the above (see discussion)

BCP is inappropriate for the document in its current state because:

   o Too much text is ambiguous or vague

   o Specified requirements conflict with widespread current practice
     unsuitable for immediate instantiation

   o A phased roll-in would be more appropriate considering conflicts
     with current practice

   o Despite hyperbole to the contrary, the document has not been
     subject to adequate community deliberations

The document suffers from the following serious defects:

   [X] missing IANA considerations

   [X] inadequate security considerations

   [X] incompatible with the Internet Architecture (RFC 1958).  In
       particular, authentication specified is not end-to-end (RFC 1958
       section 2.3), terminology is unclear and inconsistent (section
       3.13), and security has not been adequately addressed (section 6
       and subsections).

   [X] incompatible with one or more approved Internet specifications

   [X] uses non-standard, inconsistent, or poorly-defined terminology
       which may lead to confusion, misinterpretation, and loss of
       interoperability

   [X] not backwards compatible with widely deployed,
       standards-conforming infrastructure

   [X] [R7.BCP14] is referenced, but keywords are not used, or are used
       inappropriately

Specific examples of the aforementioned issues include:

   o Draft section 2 states that an MSA is always used for "submission",
     but that is not universal current practice.  Many service providers
     support only MTAs, and messages may be initially transported by an
     MUA sending to an MTA.

   o The same draft section refers to an "inbox", which is not defined.
     It is unclear whether the term is intended to be a "mailbox", as in
     "A mailbox receives mail" [R8.RFC822], [R9.RFC2822].

   o A statement is made in the same draft section that an MDA delivers
     to the undefined "inbox" which is part of an MUA; however in
     reality, an MDA may deliver to a message store which an MUA
     accesses via a separate "pull" mechanism (e.g. file access, POP,
     IMAP).

   o In some cases, an MDA may continue transport of a message based on
     per-mailbox forwarding, aliasing, or list expansion operations.  As
     noted in [R10.RFC2821], "It is sometimes difficult for an SMTP
     server to determine whether or not it is making final delivery".

   o Draft section 3 refers to "sender", which is not defined.  It is
     unclear whether this term refers to an SMTP client or to some user
     or to a mailbox ([R9.RFC2822]) or to some other entity (or indeed
     if the term is inconsistently used).  With no definition of
     "sender", it is unclear what is meant by "sender authentication".

   o Section 3 also refers to "the final MTA-to-MDA transmission",
     ignoring the caveat in [R10.RFC2821].

   o It also refers to "MDA-to-MUA delivery" contrary to actual
     operation (use of access protocols by MUAs as noted above).

   o The same draft section refers to a "relationship between client and
     server" but does not specify what the nature of the supposed
     relationship is; it is possible that what is meant is that there
     may be a contractual agreement between a user responsible for
     initiating message transfer (but that is not a "client" as that
     term is used in relevant approved Internet specifications relating
     to the mail system) and the administrative entity operating an MSA
     (but that administrative entity is not itself a "server" as that
     term is used).

   o The same section claims that "the MDA can determine that it will be
     effecting final delivery" in direct contradiction to the statement
     quoted above from the approved Internet specification contained in
     [R10.RFC2821].

   o While the qualifying word "typically" appears in part of the
     compound statement discussed above, the section goes on to imply
     that all "MSAs and MDAs can take advantage of having prior
     relationships", whereas that is only true for a subset of cases.
     In this case as well as the example noted above, it is likely that
     the "relationship" is not between MSA/MDA and "users", but is a
     contractual arrangement between some user and some administrative
     entity in the one case, and is a configuration item linking an
     MDA's operation to a mailbox (as defined in [R9.RFC2822]) in the
     other case.

   o The first bullet point at the end of draft section 3 uses the
     undefined term "submitting entity".  It is unclear whether that
     term refers to an SMTP client host, to a particular piece of
     software running on some host, to a responsible human user, or to
     some other entity.

   o That bullet point uses a BCP 14 imperative keyword, but no
     rationale or justification is given corresponding to the
     restrictions on usage for such imperatives as specified in section
     6 of BCP 14.

   o That bullet point also refers to "all mail submission mechanisms",
     and a subsequent part of the draft makes a nebulous reference to
     treating ordinary transfer "as mail submission".  Earlier draft
     text refers to software which incorporates multiple functions.  It
     is unclear precisely whether these are meant to be included in
     "all", or if "all" is being used carelessly.

   o The second bullet point uses awkward wording which is at best
     extremely difficult to parse.  It should be reworded to remove
     ambiguities so as to prevent likely incompatible interpretations.
     Specifically:

      * See above re. bizarre use of punctuation.

      * The term "received from" is undefined.  Does this refer to an IP
        address?  Something else?

      * "local operational environment" is extraordinarily vague.  What
        is the term supposed to mean?  The only constructive comment
        that can be made about such an extremely vague and poorly worded
        statement in a document intended for Standards Track or BCP is
        that its presence precludes reaching consensus agreement to the
        intended meaning of the specification in the document (since the
        intent is not communicated sufficiently clearly).

      * It fails to account for the difficulty in determining when
        "final delivery" takes place, as noted in [R10.RFC2821].

   o The third bullet point at the end of draft section 3 has problems
     of a similar nature and number:

      * "coming from" is undefined.  The lack of a definition is
        compounded by the similarity to, but distinct difference from,
        the earlier undefined term "received from".  One wonders not
        only what is meant by each of those terms, but what distinction
        is being made by the use of subtly different terms.

      * Likewise, "operator's local environment" is undefined and is
        similar to but distinct from the earlier undefined term "local
        operational environment".  The same concerns as immediately
        above also apply to this pair of undefined terms.

      * A BCP 14 imperative keyword is used with no rationale for such
        an imperative.

      * reference is made to transfer "treated as mail submission", but
        the meaning is unclear; does this refer to an implied permission
        to mangle message content?  To something else; if so
        specifically what is included and what is excluded?

      * The terms "authorization" and "validation" are used but are
        undefined by the draft (and no specific external reference is
        supplied) in that context.

      * It uses the term "RCPT-TO address" in a manner which is
        self-inconsistent (vs. "RCPT TO address" in section 4), is
        inconsistent with approved internet specifications (
        [R11.RFC821] and [R10.RFC2821]), both of which associate a
        "path" (not "address") with the RCPT TO (not hyphenated)
        command, and conflicts with other standard use of the term
        "address" (e.g. IP address, [R9.RFC2822] "address" (mailbox or
        named group)).

   o The last bullet point in draft section 3 also uses undefined terms,
     BCP 14 imperative keywords with no justification or rationale, and
     conflicts with current practice:

      * "recipients" is undefined.

      * "arrangement" is nebulous

      * no rationale for "SHALL NOT"

      * Some mail system operators provide a "catch-all" mailbox; the
        bullet point could be construed as prohibiting that current
        practice.

      * "delivery" is vague, especially in light of [R10.RFC2821] and
        forwarding, aliasing, list expansion, and the noted difficulty
        in determining when final delivery takes place.

   o The first sentence of the first paragraph of draft section 4 has a
     conflict between the words "desiring" and "need"; clearly either
     one term is too weak or the other is too strong.  The remainder of
     the paragraph is extraordinarily vague, and it is difficult to see
     how either a need or desire for end-to-end privacy is related to
     the hop-by-hop transfer implied by the draft text.  End-to-end
     privacy can be obtained with security multiparts as used by S/MIME
     and PGP/MIME, and are unrelated to transfer (except to the extent
     that transfer:

      * must not corrupt content, invalidating digital signatures

      * requires an end-to-end privacy mechanism to ensure privacy (i.e.
        if a transport intermediary is able to defeat security, there is
        no privacy)

      ).

   o The draft text makes an extremely brief reference to blocking of
     the SMTP well-known port number (25).  It claims that it "can be
     problematic for some users", but that is incorrect and
     irresponsibly understates the scope of the problem.  Blocking port
     25 precludes use of the SMTP VRFY command to determine the validity
     of a mailbox (e.g. [email-masked]).  With the ability to verify
     by a concise SMTP transaction blocked (N.B. none of RFC 2476, its
     draft successor, and/or the draft under discussion require support
     for VRFY in the "submission" protocol), it becomes necessary to
     transmit a full-blown message and hope for the best.  In the event
     of an invalid, expired, etc. mailbox, the typical result will be an
     additional delivery notification message which typically contains
     the entire original message plus transport markings plus plain text
     plus structured information regarding non-delivery, plus additional
     transport markings.  The resulting volume of (unnecessary if port
     25 is not blocked) traffic affects *all* users.  Port 25 blocking
     thus results in precisely the sort of situations for which use of
     BCP imperatives are intended, and the blocking and the harm which
     it causes should be proscribed by use of suitable BCP 14 text, e.g.
     "The well-known SMTP port MUST NOT be blocked".  It is
     irresponsible to misstate the scope of the problem caused by
     blocking ("some users") and to fail to address the problem by
     appropriate use of BCP 14 imperatives, especially as such
     imperatives are elsewhere used with no apparent justification.

   o Draft section 4 makes the (probably unintentionally) humorous claim
     that the draft document *uses* a particular TCP port.

   o The first bullet point at the end of draft section 4 is unclear
     because of:

      * Bizarre misuse of punctuation.

      * Unjustified use of BCP 14 imperative keywords (which conflicts
        with current practice).

      * The undefined term "support".  Does a server which always
        responds with a 421 greeting response code count as "support"?
        What about software that has a configurable option, but is
        operated with the option disabled?

      * The undefined term "local environment".

      * Direct conflict with approved Internet specifications RFC 2476
        and its draft successor, which both explicitly permit use  of
        the submission protocol on the well-known SMTP port (25).

   o The second bullet point in draft section 4:

      * Uses a BCP 14 imperative keyword with no rationale or
        justification

      * Does not define what or who is the object of "authentication",
        by what or whom, or on what basis or for what purpose.

      * Uses the term "RCPT TO address" in a manner which is
        self-inconsistent (vs. hyphenated "RCPT-TO address" in section
        3), is inconsistent with approved internet specifications
        ([R11.RFC821] and [R10.RFC2821]), both of which associate a
        "path" (not "address") with the RCPT TO command, and conflicts
        with other standard use of the term "address".

   o The third and last bullet points in draft section 4 presume that
     MSAs are in universal use, which is not currently true.  The last
     bullet point further presumes:

      * that there exists some MSA (as opposed to an MTA) operating on
        some host that can be used, and

      * that MUAs universally can be configured to use port 587, and

      * that somebody is able to perform the necessary configuration.

   o The figure in draft section 4 and the accompanying text refer to a
     "'home' MSA", which is nowhere defined.

   o The figure and text also presume the availability of a suitable MSA
     using port 587; both presumptions do not conform to universal
     current practice.

   o Draft section 5 conflates authentication and authorization.

   o Draft section 5 mentions POP-before-SMTP, which has known security
     defects and which therefore should not be encouraged; at minimum it
     should be strongly deprecated, ideally it would be prohibited with
     a corresponding BCP 14 imperative due to the security risks.

   o Draft section 5 fails to provide for authentication of an SMTP
     server to the connecting client, as discussed on the IETF
     discussion list regarding man-in-the-middle "evil twin" attacks.

   o In light of discussions on the IETF discussion list, the draft
     security considerations section is woefully inadequate.

   o The draft lacks the required IANA considerations section.

   o The normative references include:

      * RFC 821, which has been obsoleted according to the rfc-index and
        std-index

      * RFC 2476, which has Proposed Standard status

      * RFC 2821, which has Proposed Standard Status

      These may constitute improper downward references for a document
      intended as BCP.

   o BCP 14, a.k.a. RFC 2119, is improperly listed as an informative
     (rather than normative) reference.

   o Additional references may be required if external references are
     needed for terms which are presently undefined.

   o The Authors' Addresses section conflicts with the draft page one
     heading.

Please carefully review the references and resources indicated:

   [X] [R12.FYI36]

   [X] [R13.BCP22]

   [X] [R14.BCP26]

   [X] [R15.BCP61]

   [X] [R16.BCP72]

   [X] [R17.BCP97]

   [X] [R18.BCP104]

   [X] [R19.RFC1796]

   [X] [R20.RFC1925]

   [X] [R21.RFC1958]

   [X] [R22.RFC2223]

   [X] [R23.RFC3426]

   [X] [R24.RFC3439]

   [X] [R25.Errata]

The following applies to the document being reviewed:

   [X] The document needs substantial rework before serious review can
       take place.  In particular, substantive comment on any principles
       or practices which may have been intended is precluded at this
       time due to the extreme vagueness of the specification.  At least
       one additional broad community review cycle is desirable once the
       ambiguities, inconsistencies, etc. have been resolved.

References:

   [R1.Checklist] Wijnen, B., "Checklist for Internet-Drafts (IDs)
                  submitted for RFC publication", February 2005,
                  http://www.ietf.org/ID-Checklist.html

   [R2.ID]        Fenner, B., "Guidelines to Authors of
                  Internet-Drafts", March 2005,
                  ftp://ftp.ietf.org/ietf/1id-guidelines.txt

   [R3.Instruct]  Reynolds, J. and R. Braden, "Instructions to Request
                  for Comments (RFC) Authors"
                  (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

   [R4.idnits]    http://ietf.levkowetz.com/tools/idnits/

   [R5.editor62]  RFC Editor, "Tutorial Slides",
                  ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial62.pdf

   [R6.BCP9]      Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

   [R7.BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [R8.RFC822]    Crocker, D., "Standard for the format of ARPA Internet
                  text messages", STD 11, RFC 822, August 1982.

   [R9.RFC2822]   Resnick, P., "Internet Message Format", RFC 2822,
                  April 2001.

   [R10.RFC2821]  Klensin, J., "Simple Mail Transfer Protocol",
                  RFC 2821, April 2001.

   [R11.RFC821]   Postel, J., "Simple Mail Transfer Protocol", STD 10,
                  RFC 821, August 1982.

   [R12.FYI36]    Shirey, R., "Internet Security Glossary", RFC 2828,
                  May 2000.

   [R13.BCP22]    Scott, G., "Guide for Internet Standards Writers",
                  BCP 22, RFC 2360, June 1998.

   [R14.BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", BCP 26,
                  RFC 2434, October 1998.

   [R15.BCP61]    Schiller, J., "Strong Security Requirements for
                  Internet Engineering Task Force Standard Protocols",
                  BCP 61, RFC 3365, August 2002.

   [R16.BCP72]    Rescorla, E. and B. Korver, "Guidelines for Writing
                  RFC Text on Security Considerations", BCP 72,
                  RFC 3552, July 2003.

   [R17.BCP97]    Bush, R. and T. Narten, "Clarifying when Standards
                  Track Documents may Refer Normatively to Documents at
                  a Lower Level", BCP 97, RFC 3967, December 2004.

   [R18.BCP104]   Klensin, J., "Terminology for Describing Internet
                  Connectivity", BCP 104, RFC 4084, May 2005.

   [R19.RFC1796]  Huitema, C., Postel, J., and S. Crocker, "Not All RFCs
                  are Standards", RFC 1796, April 1995.

   [R20.RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
                  April 1996.

   [R21.RFC1958]  Carpenter, B., "Architectural Principles of the
                  Internet", RFC 1958, June 1996.

   [R22.RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC
                  Authors", RFC 2223, October 1997.

   [R23.RFC3426]  Floyd, S., "General Architectural and Policy
                  Considerations", RFC 3426, November 2002.

   [R24.RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
                  Guidelines and Philosophy", RFC 3439, December 2002.

   [R25.Errata]   RFC-Editor errata page,
                  http://www.rfc-editor.org/errata.html

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 03:40:13 +0200

> http://www.ietf.org/ID-Checklist.html:
[...]
Okay, you found nits above the typo level, draft -04
has to be fixed before it can be "last called" again.

> [R5.editor62] may be useful

An 1.5 MB PDF, so that is most probably irrelevant to
create plain text 20 KB Internet Drafts with 10 pages.
Remove {R5] from your references please, or at the
very minimum add a warning about its size.

> the status as defined in [R6.BCP9] should be:

Let's assume that we know the list of possibilities,
and just state what you think...

> [X] Informational

...something's wrong if your review is longer than
the reviewed source.

>    o Too much text is ambiguous or vague

Statements like this are vague and therefore almost useless.

> [X] incompatible with the Internet Architecture (RFC 1958).

This "exponential-growth-info" is no standard of any kind,
please remove [R21] from your list.

> [X] incompatible with one or more approved Internet

Care to name one or more specifications ?

> [X] uses non-standard, inconsistent, or poorly-defined

Which "standard terminology" are you talking about ?

The draft references exactly three normative texts,
you might get some more recursively, so if there's a
conflict please _show_ it.  I can't check vague claims
based on what you might consider as "standard".

> standards-conforming infrastructure

If there's a problem with 2476bis I didn't see it,
except from the obvious s/2476/gellens-submit-02/

> o Draft section 2 states that an MSA is always used
> for "submission", but that is not universal current
> practice.  Many service providers support only MTAs,
> and messages may be initially transported by an MUA
> sending to an MTA.

As defined in 2476bis that's a special case of an MSA:

| A site MAY choose to use port 25 for message
| submission, by designating some hosts to be MSAs and
| others to be MTAs.

And as far as I can tell it this _is_ current practice.

> o The same draft section refers to an "inbox", which

Actually "inbox" is defined in the next statement, but I
agree that this definition is somewhat beside the point
in a piece of text about MDAs.

> o In some cases, an MDA may continue transport of a
> message based on per-mailbox forwarding, aliasing, or
> list expansion operations.

If it's no final delivery it's no MDA.

> "It is sometimes difficult for an SMTP server to
> determine whether or not it is making final delivery".

Difficult or not, it will decide this, otherwise it's a
Schroedinger-MTA or science fiction.

> Draft section 3 refers to "sender", which is not
> defined.

It's defined in STD 10, everybody knows what it is.
And in the context of chapter 3 it's the submitter.

> it is unclear what is meant by "sender authentication".

The complete chapter 3 explains what it's supposed to
be for an MSA, "submitter authentication".

> Section 3 also refers to "the final MTA-to-MDA
> transmission", ignoring the caveat in [R10.RFC2821].

"551 user not local" is an old and simple concept, not
the stuff to write a new BCP about.  The idea in the
draft is to reject mails to unknown local users a.s.a,p.
instead of first accept and later bounce such crap.

And that's indeed "best current practice" everywhere.

> It also refers to "MDA-to-MUA delivery"

What term do you propose to catch all these wild and
wonderful ways to get mail from an MDA to the user ?
This "MUA" could be a Webmail interface, it could be
IMAP, POP3, some ETRN or ATRN trick, UUCP, what else.

Maybe "mailbox-by-MUA access" ?

> The same draft section refers to a "relationship
> between client and server" but does not specify
> what the nature of the supposed relationship is

This "supposed relationship" can be whatever the site
wants it to be, the text simply states "MUST perform
 authentication during mail submission, based on an
 existing relationship with the submitting entity."

This MUST directly reflects the MUST in chapter 4.3
of 2476 or 2476bis, it's nothing new.

> "the MDA can determine that it will be effecting
>  final delivery" in direct contradiction to the
> statement quoted above from the approved Internet
> specification contained in [R10.RFC2821].

Yes, something might be odd here, because if it's
not effecting final delivery it's no MDA, and that
might be a kind of circular definition.

> undefined term "submitting entity"

2476(bis) defines MSA and MUA, it must be the latter
in this case.  I'm less sure about "formail" forms,
that could be a special case of "submitting entity".

> That bullet point uses a BCP 14 imperative keyword

Yes, it's simply the 2476(bis) 4.3 MUST, see above.

 [chapter 3, 3rd bullet]
> A BCP 14 imperative keyword is used with no rationale
> for such an imperative.

That's about open relays.  Treat mails from unknown
strangers to unknown strangers as submission.  In fact
this MUST is odd.  An open relay is no MSA, saying that
it MUST be an MSA (and reject the mail) is pointless,

> the meaning is unclear; does this refer to an implied
> permission to mangle message content?

Submit / MSA is defined in 2476(bis) and perfectly clear.

> The terms "authorization" and "validation" are used but
> are undefined by the draft

The draft is no _reprint_ of gellens-submit-02 (2476bis),
it's a BCP _based_ on 2476(bis).

> no specific external reference is supplied

Okay, maybe they should first submit it to the SPF-community,
we're training to get I-Ds in shape for your famous reviews,
see <http://mid.gmane.org/[email-masked]>.

So what's it, missing informative RfC 2828 reference, right ?

> The last bullet point in draft section 3 also uses undefined
> terms, BCP 14 imperative keywords with no justification or
> rationale

The MDA oddity again.  The idea is simply "reject instead of
accept and later bounce", but that's a job for the MX, not
for the MDA.

I skip your chapter 4 comments because it's getting too long.
As far as blocking port 25 is concerned I tend to agree with
you, but not to the point of a "MUST NOT".

For obvious reasons there's nothing wrong with blocking known
abuse.  And the draft just says "no recommendation".

> * Bizarre misuse of punctuation.

Spelling flames were already lame when I was much younger. :-(

> The figure and text also presume the availability of a
> suitable MSA using port 587; both presumptions do not
> conform to universal current practice.

It's the point of this text to offer MSAs for roaming users
even under "bizarre conditions" like a blocked port 25.

> Draft section 5 mentions POP-before-SMTP, which has known
> security defects

Depends on how you do it, it can be perfectly sane and even
better than the non-standard SMTP AUTH "LOGIN" scheme, or
PLAIN without TLS (not allowed, but not everybody knows it).

If it's coupled with 2476(bis) "enforced submission rights".

> ideally it would be prohibited

Removing features instead of doing it right or fixing them
is a stupid strategy.  This is an Internet Draft and not a
"security update" from whose-name-must-not-be-named.

> The normative references include:
> * RFC 821, which has been obsoleted according to the
>   rfc-index and std-index

My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

> * RFC 2476, which has Proposed Standard status

RfC 2476bis is AFAIK approved as Draft Standard.  See also:
<http://mid.gmane.org/[email-masked]>

> [R3.Instruct]
[...]
> (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

Expired.

> [R12.FYI36]
[...]
> RFC 2828, May 2000.

Oops, there it is.  Note that 2476bis also doesn't use it,
nothing forces authors to use a glossary they don't like.

                          Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 11:25:24 -0400

> has to be fixed before it can be "last called" again.

Credit goes to Henrik Levkowetz' idnits program.

> create plain text 20 KB Internet Drafts with 10 pages.

Heavens to Betsy, a whole floppy disk's worth of space :-).
It gives advice on writing comprehensible text (slides 42 through 54
are pertinent to the draft under discussion) among other things.

> Statements like this are vague and therefore almost useless.

That's in a summary and is supported by detailed comments on specific
draft text which is ambiguous and/or vague.

> please remove [R21] from your list.

It is unclear what you're referring to; specific sections of RFC 1958
were referenced.
 
> Care to name one or more specifications ?

Aside from RFC 1958, the review specifically mentioned issues related
to RFCs 2821, 2476, BCP 14, and security multiparts (not referenced by
RFC number, which is 1847).
 
> Which "standard terminology" are you talking about ?

Several cases were specifically mentioned (e.g. "RCPT-TO address"
vs. RCPT TO path (no hyphen and "path" as used in RFCs 821, 2821)).
 
> except from the obvious s/2476/gellens-submit-02/

E.g. the conflict between 2476 et seq "MAY choose to use port 25" vs.
draft under discussion "MUST support the SUBMISSION port".  There are
of course other issues as listed in the review.
 
> | submission, by designating some hosts to be MSAs and

No, while 2476 permits use of port 25 for an MSA, it does not specify
that use of port 25 automatically changes an MTA into an MSA.  MTA
transfer (other than gateways) precludes message modification; an
MSA is explicitly permitted by 2476 to modify message content without
notice to or approval of the client or author, and the draft's "treat
as submission" appears to encourage such unauthorized modification *by
MTAs*.
 
> And as far as I can tell it this _is_ current practice.

Unauthorized message modification may indeed be current practice in
*some* places, but it's not *best* current practice, and in any event
although the abbreviation "BCP" stands for best current practice, the
BCP series of RFCs has specific uses as specified in BCP 9 and as
paraphrased in the review; the draft under discussion fails to meet
several of the requirements for BCP as noted in the review (and by
others in IETF discussion list comments).

> Actually "inbox" is defined in the next statement,

I see no *definition*.  Nothing resembling one.

> If it's no final delivery it's no MDA.

The underlying problem may be the lack of definition of an MDA.  As
far as I'm concerned, aliasing, forwarding, and list expansion take
place at an MDA, when the mailbox local-part is interpreted.  Such
interpretation is a delivery operation rather than a transport operation
as it involves changes to the SMTP envelope.  That the same message
(RFC 2822 sect. 3.6.4) is again transported as a result of delivery
to a mailbox simply means that the delivery isn't "final" (and in
practice this may happen via a distributed mechanism such as a Sieve
script, such that other mail system components cannot determine whether
or not delivery is "final").
 
> Schroedinger-MTA or science fiction.

See above and RFC 3028 (esp. sect. 4.3).  Also, think about the word
"gateway" for a moment or two.
 
> And in the context of chapter 3 it's the submitter.

RFC 821 refers to "sender-SMTP" and to "the sender" and "the sender
mailbox", but provides no definition.  Use is not sufficiently
consistent to infer a definition; e.g. "the sender of the HELP command"
appears to refer to an SMTP client implementation (maybe "sender-SMTP"),
but a client certainly need not have a "sender mailbox".

RFC 1869 does not contain the word "sender" at all, and RFC 974 uses
the word exactly once, not as a definition.

> be for an MSA, "submitter authentication".

The draft doesn't say what is being used (IP address? HELO/EHLO domain?
MAIL FROM path? message header field content? something else?), and
because some of those have been attempted to be used in inappropriate
circumstances, causing harm to the Internet, a vague blanket statement
such as in the draft under discussion is unsuitable as BCP or as a
Standards Track RFC precisely because it encompasses those harmful
practices.  The draft needs to be specific about precisely what may
and may not be used as a basis for authentication/authorization/validation,
of what/who, by what/whom, under which circumstances, and for what
specific purposes.  In addition, at least something needs to be said
about some specific methods which have known limitations or flaws.

> instead of first accept and later bounce such crap.

That's not what the draft says.  Nor is it at all clear that that is
the intent.  Indeed, the draft never once mentions "bounce" or the
more precise "notification".
 
> IMAP, POP3, some ETRN or ATRN trick, UUCP, what else.

None of webmail, POP3, nor IMAP involve delivery; they are either "pull"
or "access" mechanisms associated with a message store of some sort.
ETRN is specifically prohibited by RFC 2476 et seq.   "ATRN" is only
mentioned in RFC 2645, which has been stuch at Proposed Standard for
six years, presumably because there aren't two implementations.  UUCP
is a low-level transport mechanism which is incapable of "to-MUA
delivery"; it sends files that may be saved to a message store.

> Maybe "mailbox-by-MUA access" ?

The (convoluted and vague) text appears to be discussing MDAs, not
recipient MUAs.  I see no reason to mention recipient MUAs at all.
 
> wants it to be,

As noted above, that's a problem because some of the "whatever" is
harmful.

> might be a kind of circular definition.

No definition at all.
 
> in this case.

So is it a person, a piece of software, a host, an IP address, or
what?

> Yes, it's simply the 2476(bis) 4.3 MUST, see above.

Where's the justification for an imperative?
 
> Submit / MSA is defined in 2476(bis) and perfectly clear.

It's not at all clear (specific 2476 et seq issues were discussed on
the IETF discussion list several months ago), and the draft under
current discussion is unclear about what "treat as submission" entails
(as noted by several reviewers).
 
> accept and later bounce",

That's your interpretation, not anything explicitly stated in the
document under discussion.   For Standards Track and BCP documents, we
need a clear specification, not something that will be interpreted in
dozens of different, incompatible, non-interoperable ways.

> Spelling flames were already lame when I was much younger. :-(

The comment has nothing to do with spelling. 

(draft-under-discussion punctuation mode on)
If you, think, that adding random, commas, improves readability, you,
are mistaken.  It obfuscates, the meaning.
(bizarre punctuation mode off)

> even under "bizarre conditions" like a blocked port 25.

The text can offer whatever its authors like.  The reality is that
many service providers do not provide MSAs, some that do choose to
use port 25 (as explicitly permitted by RFC 2476 et seq.), and that
combinations of requirements in the draft will cause serious damage
to the Internet unless a phased roll-in is used.

> PLAIN without TLS (not allowed, but not everybody knows it).

No. No matter what, there is an open window that an attacker can
exploit.  Also, basic POP3 uses plaintext USER and PASS commands;
use of that with SMTP-after-POP gives an attacker access to not
only SMTP, but to POP as well.
 
> is a stupid strategy.

Opening a window for exploit by attackers is a stupid strategy.

> My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

std-index also says RFC 974.  std-index and rfc-index both say 821 et al.
are obsoleted by 2821, and 2821 itself says so.
 
> > (draft-rfc-editor-rfc2223bis-08.txt), July 2004.

"Active" and "IESG Evaluation" according to the official Internet-Drafts
Database.  Your source?

> nothing forces authors to use a glossary they don't like.

True, but the draft's security considerations section is unacceptable,
and as it needs a rewrite, the authors should consult the appropriate
guidelines (BCP 72) and use standard terminology (FYI 36).  They can
of course ignore both, at the risk of having to rewrite yet again.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 21 Jun 2005 23:00:45 +0200

> Credit goes to Henrik Levkowetz' idnits program.

ACK.  [After some debugging with his help I found a
way to use the Web service, it works fine with Lynx]

 [1.5 MB PDF]
> Heavens to Betsy, a whole floppy disk's worth of space :-).

Won't impress my nice USR Courier and AcroReader 3.0 -
I'll wait until you quote it again for an I-D where I
promised that it would survive your review.

> That's in a summary and is supported by detailed
> comments on specific draft text which is ambiguous
> and/or vague.

Maybe swap "specific examples" and "comments".  Or
replace "comments" by "summary".  Or add "specific
examples shown below" to the "serious defects".

I simply tried to read it top down (jumping from
RfC 2476bis to the I-D and back in another window).

> It is unclear what you're referring to; specific
> sections of RFC 1958 were referenced.

This "incompatible with the Internet architecture",
your death sentence.  You could as well quote KISS
(3.5), the principle of constant change (1), build
on the work of others (3.2), running code (3.14),
or don't wait for perfect solutions (3.7).  In some
way or another all relevant for hutzler-spamops-04.

> security multiparts (not referenced by RFC number,
> which is 1847

You never stop to amaze me with RfC numbers I have
never before heard of...  oh, that stuff, okay, now
where's that related to MSA and MDA considerations ?

All they have to decide is "is this a submission ?",
"if yes, when should I accept it ?", "is this for
a local user ?", and "if no, what should I do ?".

Not at all related to the DATA or a potential MIME
multipart/signed or multipart/encrypted body.  Dave
is listed in the RfC 1847 credits, so he would know
if there's any problem.  I certainly don't see it.

> e.g. "RCPT-TO address" vs. RCPT TO path (no hyphen
> and "path" as used in RFCs 821, 2821)

Okay, I'd interpret it as the address identifying the
mailbox in the forward path.  Or as RfC 821 put it,
"the mailbox is an absolute address", "to emphasize
the distinction between an adress and a route".

So "RCPT-TO address" is a forward-path minus route,
what else should it be.  The hyphen might be a typo.

 [skipping some text where we probably disagree]
> The underlying problem may be the lack of definition
> of an MDA.

Point, 2476(bis) offers only MUA, MSA, and MTA.  And
your concept makes sense, but not in conjunction with
some ideas in the draft.

> other mail system components cannot determine whether
> or not delivery is "final"

Then they have to assume that it is, and if something
beyond their control has its own ideas it's responsible
to get it right, e.g. a mailing list.

> See above and RFC 3028 (esp. sect. 4.3).

MUA-stuff, a MUA claiming to be no MUA is still a MUA.

> think about the word "gateway" for a moment or two.

Yes, MUAs claiming to be a gateway are often a PITA.

  [submitting entity]

> So is it a person, a piece of software, a host, an IP
> address, or what?

It's something with an IP connecting to port 25 or 587
saying HELO or EHLO.  And if that's you using telnet
it's perfectly okay.

> Where's the justification for an imperative?

In section 4.3 of 2476(bis), without authentication it
would be an open relay and no MSA.  Normally I'd hate
"green MUST be a colour" statements, maybe there's an
odd weak point in the draft and 2476(bis).

> If you, think, that adding random, commas, improves
> readability, you, are mistaken.  It obfuscates, the
> meaning.

Only typos, nothing bizarre about it from my POV.

  [SMTP-afer-POP]

> No. No matter what

Now wait, my next statement belonged to this part:

| If it's coupled with 2476(bis) "enforced submission rights".

> there is an open window that an attacker can exploit.

He had to get the "enabled" IP and had to know the MAIL FROM.

> Also, basic POP3 uses plaintext USER and PASS commands;

When I said _can_ be better than AUTH "LOGIN" it was of course
not about USER PASS.  But APOP can be already slightly better.

> std-index also says RFC 974.  std-index and rfc-index both
> say 821 et al. are obsoleted by 2821, and 2821 itself says
> so.

RfC 2821 is a "proposed standard", and for some of the more
obscure RfC 821 features like SAML or SOML it says "read 821".

Besides RfC 821 had a logical concept of MAIL FROM, at least
in theory, where RfC 2821 offers only a "we broke it, sorry".

 [rfc2223bis-08.txt]
> "Active" and "IESG Evaluation" according to the official
> Internet-Drafts Database.  Your source?

A local copy of the draft, line 11:  "Expires: February 2005".

                           Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 19:53:18 -0400

> Won't impress my nice USR Courier and AcroReader 3.0 -

I can't help that.  The document comments indicate that it was generated
from MS PowerPoint by Windows Acrobat Distiller in 1.3 (Acrobat 4.x) PDF
format.

> way or another all relevant for hutzler-spamops-04.

Perhaps. You're welcome to comment on issues that you think are
important.  I picked the end-to-end issue (as reaffirmed by RFCs
3426 and 3439), security issues, and consistency and clarity of
terminology.  There may well be other issues; due to the ambiguity
and vagueness (in part due to lack of clear and consistent
terminology) it's not currently possible to tell from the draft
as written.

> where's that related to MSA and MDA considerations ?

It's related to the concept of authentication/authorization and
the end-to-end principle.  It seems rather silly for some random
MTA to decide whether or not some human sender or machine is
allowed to send a message to me claiming to be from some author.
If the existing mechanisms which are capable of providing true
end-to-end authentication are used, there is absolutely no reason
for some intermediate MTA to try to play nanny.
 
> mailbox in the forward path.
[...]
> So "RCPT-TO address" is a forward-path minus route,

The point is that if the perfectly fine terminology used in the
primary reference is used in the draft itself, there is no need
for interpretation (i.e. "guessing").

> MUA-stuff, a MUA claiming to be no MUA is still a MUA.

No, RFC 3028 is Sieve, which "is not tied to any particular
operating system or mail architecture"; it can be run in an MUA,
but can also be run elsewhere.  See the RFC 3028 Abstract and
Introduction.

> Yes, MUAs claiming to be a gateway are often a PITA.

No, nothing to do with MUAs.  An MTA acting as a gateway might
indeed make final *SMTP* delivery, but not final delivery; moreover
a subsequent gateway may reintroduce the message into SMTP.  In
other cases, the MTA may be unable to determine whether delivery
is to a message store or to a temporary spooling area for subsequent
gateway processing.

In particular, your interpretation about "reject instead of accept
and later bounce" is inapplicable in the case of many gateways; the
gateway has no way to determine validity of the recipient mailbox
equivalent -- if it turns out to be invalid, a "bounce" may well be
the only way to provide an indication to the originator.  [in more
general terms, that interpretation means little if multiple "hops"
of store-and-forward (SMTP) is used; if one late hop results in a
permanent error reply code (or a timeout, etc.) the intermediate
MTA that accepted and stored the message before attempting to send
to the MTA or MDA that might be able to reject the message still
needs to send a "bounce", as that is specifically required by RFC
2821 sections 2.1, 3.3, 3.7, 4.1.1.4, 4.2.5, 6.1.]

> saying HELO or EHLO.  And if that's you using telnet

But it's still not clear what it is that is supposed to be
authenticated.

> would be an open relay and no MSA.

The draft still lacks a justification corresponding to BCP 14
"actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)  For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for interoperability".

> He had to get the "enabled" IP and had to know the MAIL FROM.

Yes -- see the "evil twin" discussions on the IETF discussion list
related to the draft under discussion.
 
> A local copy of the draft, line 11:  "Expires: February 2005".

Expiration date can be extended (w/o changing the draft text) by request
of the author or IESG.