Subject: Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 8 Jun 2007 14:39:57 +0200

On Wed, Jun 06, 2007 at 10:32:13AM -0400,
 The IESG <[email-masked]> wrote 
 a message of 30 lines which said:

> - 'Email Submission: Access and Accountability '
> <draft-hutzler-spamops-07.txt> as a BCP

It seems that there is not a lof of content left from the first, much
more normative versions of this document, which were issued a long
time ago.

Among what is left, I'm concerned about section 3.1 "Best Practices
for Submission Operation" which says "It is also suggested that
operators standardize on the SUBMISSION port for both external AND
LOCAL users for simplicity." and "MSAs MUST perform authentication on
the identity asserted during all mail transactions on the SUBMISSION
port".

Since section 5 "Message Submission Authentication/Authorization
Technologies" mentions only SMTP AUTH and TLS, does it mean that
authentication by IP addresses is forbidden? I ask so because it is
currently the most common way to weakly authenticate local users. Is
it covered by "Depending upon the environment, different mechanisms
can be more or less effective and convenient"?

Side note: on Unix, will cron be forced to authenticate to send emails
at 2 am? :-)

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

---

From: John Levine <[email-masked]>
Date: 9 Jun 2007 20:00:49 -0000

>can be more or less effective and convenient"?

The latter.  The intention is to encourage everyone to use AUTH or
TLS, since they tend to provide better granularity than IP
authentication.  For example, it's dismayingly common to use security
holes to install scripts on web servers that send out spam.  If the
legit scripts all used AUTH when sending mail to the local mail
server, it would be immediately obvious when a rogue script were
sending mail.

>Side note: on Unix, will cron be forced to authenticate to send emails

Perhaps a sentence or two clarifying that this only applies to SMTP and
SUBMIT would be in order.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 09 Jun 2007 19:13:34 -0400

--On Saturday, June 09, 2007 20:00 +0000 John Levine 
<[email-masked]> wrote:

>> Side note: on Unix, will cron be forced to authenticate to
>> send emails at 2 am? :-)
>
> Perhaps a sentence or two clarifying that this only applies to
> SMTP and SUBMIT would be in order

But there are a large number of SOHO and consumer boxes, 
designed for use as firewalls, etc., which are capable of 
sending out mail via SMTP containing their logs.  They are not 
multi-user, are presumably difficult to compromise by virus or 
worm, and are typically configured only to send mail to SMTP 
servers they protect and hence presumably trust.  Given the 
prohibitions in this document, where are those devices left? 
Am I correct in assuming that this document would intend to 
prohibit those devices as non-conforming?

      john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 10 Jun 2007 07:12:23 -0700

Stephane,

Thanks for posting a comment.  I hope that more folks do...

> more normative versions of this document, which were issued a long

The spamops effort has been dominated by a desire to specify only things that 
are UNcontroversial, at this stage.

Many of us -- amongst the authors and certainly amongst the community -- might 
wish for more extensive and aggressive normative statements, but we recognize 
that the document would very likely not be approved. Even if approved, it 
would not be likely to gain widespread adoption.

So the goal, here, is to make a first normative step that is comfortable, in 
order to make that first step.

> the identity asserted during all mail transactions on the SUBMISSION

If you have a concern, other than the one you cite in the following text, I 
missed it.  In other words, I am assuming that your next paragraph is the 
explanation of your concern stated in the previous one, but I want to make 

> can be more or less effective and convenient"?

I do not see normative language such as "MUST NOT" or "SHOULD NOT" on this 
topic, in the document.  So I do understand why you would worry about a method 
being "forbidden".

In fact, the latter part of the paragraph says "Depending upon the 
environment, different mechanisms can be more or less effective and 
convenient. Organizations SHOULD choose the most secure approaches that are 
practical" which seems, to me, to clearly state that you are free to use any 
technique you deem sufficiently effective.

Authentication is not a particular technique, it is an assurance.  Whatever 
achieves that assurance -- to a sufficient degree and with sufficiently low 
cost -- is fine.

> Side note: on Unix, will cron be forced to authenticate to send emails

Yes.  See above.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sun, 10 Jun 2007 07:31:46 -0700

John C Klensin wrote:
> --On Saturday, June 09, 2007 20:00 +0000 John Levine <[email-masked]> 
> wrote:
> But there are a large number of SOHO and consumer boxes, designed for 
> use as firewalls, etc., which are capable of sending out mail via SMTP 
> containing their logs.  They are not multi-user, are presumably 
> difficult to compromise by virus or worm, and are typically configured 
> only to send mail to SMTP servers they protect and hence presumably 
> trust.  Given the prohibitions in this document, where are those devices 
> left? Am I correct in assuming that this document would intend to 

No.

If the devices (or cron, or whatever) are indeed sending valid mail by virtue 
of having been configured properly and not having been compromised, then it 
sounds to me as if the mail is very much authentic (and authenticated.)

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 Jun 2007 12:33:14 -0400

--On Sunday, June 10, 2007 07:31 -0700 Dave Crocker 
<[email-masked]> wrote:

>> trust.  Given the prohibitions in this document, where are
>> those devices  left? Am I correct in assuming that this
>> document would intend to  prohibit those devices as
>> non-conforming?
>
> No.
>
> If the devices (or cron, or whatever) are indeed sending valid
> mail by virtue of having been configured properly and not
> having been compromised, then it sounds to me as if the mail
> is very much authentic (and authenticated.)

Dave,

I am working on a more comprehensive review, which I will get 
posted in the next day or so.  However, while I agree with most 
of the suggestion in the draft and certainly with its good 
intentions, it contains a great deal of very strong conformance 
language ("MUST"s and "SHOULD"s) that considerably exceed 
current practice.  While I have quibbles, that would be fine as 
a target.  In particular, it would be entirely appropriate if 
this were going for Proposed Standard, subject to subsequent 
review as to which of the mandates had been followed in practice 
and adjustments as needed.    But, as a BCP with no multi-stage 
review process, it seems to me that some of those requirements 
simply do not reflect current practice, best or otherwise. 
"Desired good practices" or "really strongly recommended 
practices" or "best current wishes", possibly, but we haven't 
adopted those categories.

The devices that prompted my note show up because they are, 
typically, incapable of authenticating themselves to an SMTP 
server at all.  If there is any indication of authorization, it 
is by IP address, but the document strongly discourages using. 
Their SMTP clients are typically very weak (several are 
notorious for not even managing to include a date header, which 
has been a requirement for, at you, know, a few decades) and are 
in firmware that I'd guess is rarely updated within the life 
expectancy of the device.   On the other hand, the devices are 
pretty safe and need not be blocked: compromising them to send a 
message of the attacker's choice would be fiendishly difficult 
and they are usually configured in a way that makes them even 
safer.

There are other cases as well; more soon.

      john

---

From: Tony Finch <[email-masked]>
Date: Sun, 10 Jun 2007 19:32:00 +0100

> Side note: on Unix, will cron be forced to authenticate to send emails

cron sends email by invoking sendmail, which knows the user that invoked
it. authentication is therefore automatic and has been the norm for ever.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT PORTLAND: EAST OR NORTHEAST 3 OR 4, BECOMING VARIABLE LATER.
SMOOTH OR SLIGHT. FOG PATCHES, SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY
VERY POOR.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 10 Jun 2007 12:49:27 -0700 (PDT)

> it. authentication is therefore automatic and has been the norm for ever.

Sendmail does not authenticate automatically or otherwise. What it does
is to use as RFC2821 MAIL FROM account of the user that invoked it or
when "-f" option is used puts out account of the user in the trace data.

This is not authentication, this is reporting of the user data, so its
like you connecting to open relay mail system and that system properly
puts in Received line with ip address of where you connected from and then 
forward your email without checking if you're allowed to relay or not.

Now in theory you could say that properly setup unix system should not
allow access to sendmail (by means of user/group permissions) for
those unix accounts that should not have access to it. In practice such
precise security policies & permissions are almost unheard of.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Sun, 10 Jun 2007 21:59:28 +0100

> forward your email without checking if you're allowed to relay or not.

You seem to be confusing authentication and authorization. Sendmail
authenticates local senders but does not (by default) have any controls
over which users are authorized to send email.

The same is true for the university email system that I help run: any
account that exists (can be authenticated either as a Unix user on the
old timesharing service or via SASL for modern message submission) is
authorized to send email.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES: NORTHERLY 3 OR 4. SLIGHT. FOG PATCHES AND SHOWERS. MODERATE OR
GOOD, OCCASIONALLY VERY POOR.

---

From: Ned Freed <[email-masked]>
Date: Sun, 10 Jun 2007 13:17:39 -0700 (PDT)

> current practice.

I have to disagree with this assessment. The practices this document describes
may not be universal or even widespread, but I don't see anything the document
recommends that isn't currently practiced, in most cases on a fairly large
scale. For example, we now routinely see sites that have port 25 completely
blocked except for inbound relay and which require TLS+SASL on the submit port
to send mail.

A more important question IMO is whether or not what's recommend here is really
the best practice. In almost every case I think the answer is yes. My one
concern is with the recommendation that MSAs by default try the submit port
first and if that fails fall back to port 25. I have no problem with
recommending a submit port configuration - it's the fallback process that
concerns me. The problem I see with this is what happens if the SMTP server is
set to return an error if someone attempts to use it and the submit server gets
overloaded and doesn't respond quickly enough.

> While I have quibbles, that would be fine as

John, as you undoubtedly know, the issue of whether or not a BCP status
document can recommmend or require practices that aren't widespread has come up
several times previously, and I believe we've seen both possible outcomes: BCPs
have been issued that recommend practices that had little or not deployment at
the time the document was issued (the obvious example here are our process
BCPs, which more or less by definition aren't "deployed" until after approval)
and documents seeking BCP status have on occasion been shifted to the
three-step standards track.

In regards to the current document, I think this fits better as a BCP but I
would not object to making it a proposed standard instead. But this really
should be up to the IESG to decide.

> is by IP address, but the document strongly discourages using.

Hmm. Well, I looked but I don't see any statements along these lines in there.
Regardless, I actually would not object to a SHOULD use credentialed
authentication as this leaves a reasonable loophole for devices that are
incapable of it.

> and they are usually configured in a way that makes them even

A fair number of them are egregiously incompliant in other more serious ways,
e.g. not having adequate timeouts or sufficient retry logic. But irrespective
of the problems in this area I really don't tnink catering to device breakage
or limitations by compromising compliance language that's urgently needed to
deal with the spam problem is a reasonable tradeoff.

				Ned

---

From: Tony Finch <[email-masked]>
Date: Mon, 11 Jun 2007 02:26:53 +0100

On Sun, 10 Jun 2007, Ned Freed wrote:
>
> My one concern is with the recommendation that MSAs by default try the
> submit port first and if that fails fall back to port 25. I have no
> problem with recommending a submit port configuration - it's the
> fallback process that concerns me.

In my ideal world, MUAs would auto-configure using a one-off probe and
fallback process, and remember the results in the same way they currently
do after manual configuration. Any subsequent failure should require
manual intervention from the user (even if it's just to confirm a
re-probe) since it might imply that an attack is in progress.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
TRAFALGAR: SOUTHWESTERLY 3 OR 4, OCCASIONALLY 5 IN NORTHWEST. SLIGHT OR
MODERATE. SHOWERS. GOOD.

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Jun 2007 06:01:33 -0400

Hi.

As indicated in an earlier note, I've got considerable
misgivings about this document.  Sorry it has taken me this long
to draw my notes together and get them posted.

Metacomment: Many or most of my concerns about this document
would disappear if it were placed on the normal standards track
as a Proposed Standard, followed by a review after some months
of which features and recommendations really had received
considerable implementation and deployment and proven effective
in practice.   While use of BCP for IETF procedures and the like
is, IMO, just an unfortunate terminology twitch, use of BCP to
eliminate the multistage process for what is clearly a protocol
document --even one that slides over into the territory of a
somewhat speculative A/S-- seems dubious to me and devalues
those BCPs that really are recommendations based on best current
practices rather than speculation about future ones.   As noted
below, this document even appears to update RFC 2821, altering
one of its requirements.

While I wouldn't particularly recommend it, those concerns could
also be satisfied by some rephrasing of comments followed by
Informational publication.

I want to stress that I agree with the intent of every
recommendation in this document.  It is the document itself and
occasionally the requirement levels, but not the recommendations
themselves, that are inadequate or inappropriate, especially for
a one-step approval/publication process.

Even the comments below that have nothing to do with status
(possibly modulo the concerns about an inadequate Security
Considerations section) probably fall into the "good enough for
Proposed" category... but not good enough for a one-step model. 

I also note that the IETF has experimental protocols (SPF, etc.)
and a standards-track effort (DKIM) about which some fairly
optimistic claims have been made about their ability to limit
spam or control its effects.  It would be sad to issue this
document as a BCP and then turn around and issue an update that
contained a different (even if broadly consistent) set of
recommendations were one of those techniques to prove as
successful as their most passionate advocates predict.

Specific remarks:

(1) While this document talks about a "wide variety of email
authentication techniques..." (Introduction, paragraph 3), the
reality is that these are generally not authentication
techniques for email but for the server chain.  Their strength
depends on the assumption that the sending endpoint (MUA and
MSA) will have adequately validated the sending user.  However,
in most cases with these techniques, the strongest validation
assumes that the mail is valid if it comes from a machine which
is authorized to send mail over a particular path.  That would
constitute reasonably strong user (and hence email)
authentication (a "confirmed identity of the originator") if the
sending machine were trusted and known to strongly authenticate
user accesses.  But, on an Internet where the most common
practice is to assume that possession of an end-user client
machine constitutes authorization to use it, that assumption is
dubious.

Each time the IETF community has attempted a serious analysis of
"email authentication", the conclusion has been that the only
methods that really work are based on end-to-end message
authentication involving digital signatures and message
integrity checks of some persuasion.  While the difficulties
with wide deployment or those methods are well-understood at
this point, the IETF should not be publishing a Best Practices
document that implies that less reliable techniques are
equivalent or even that they are "email authentication".

All in all, there are a series of initial authentication and
authorization and chain of trust assumptions built into the
techniques recommended here whose "security considerations"
analysis is woefully inadequate either directly or by reference.
Rather than discussing these issues, the "Security
Considerations" section merely says that there is a problem and
that these recommendations can help with it.

(2) Section 3.1 contains a MUST requirement for availability of
the message submission port (RFC 4409).  While I am a firm
believer in RFC 4409 and look forward to the point at which we
can put out a document that deprecates the use of SMTP (RFC
2821) for message submission by clients that do not support full
SMTP services (for many more reasons than spam mitigation), we
aren't there yet, and a MUST requirement definitely does not
represent current practice.

A subsequent subsection "Submission Authentication" requires
(with a MUST) authentication on the asserted identity ... "even
for a
message having a RCPT TO address that would not cause the
message to be relayed outside of the local administrative
environment".  The IETF has historically been very reluctant to
tell people what they are permitted to do within the confines of
their own administrative environments (e.g., local or enterprise
LANs).  Even a SHOULD on this one would seem to require much
stronger justification than appears in this document; a MUST
appears to be outside IETF's knowledge and scope, at least in
the absence of a security analysis of the potential issues.

MUST provisions in the next subsection ("Submission
Authorization") raise similar issues: Validation of
authorization is certainly a fine idea but, without some more
specific text about what is intended and required, it is so much
hand-waving.  And we should not be hand-waving around a MUST.
Section 5 is apparently intended to address this issue but falls
somewhat short (see (7) below).  Editorially, if Section 5 is
actually intended to address the issues of methods, some forward
references/ pointers would be in order.

It seems to me that the provision that the tracing requirement
of "Submission Accountability after Submission" can be satisfied
by examining header information requires a comment, either
inline or in Security Considerations, about the ease or
difficulty of spoofing that information.  While the level of
sophistication required to do a good one has risen over time,
"Joe Jobs" are not exactly a recent innovation and, indeed,
several of the other techniques recommended in this document are
presumably intended, at least in part, to make them more
difficult.

By contrast, the last paragraph of the introduction to Section 3
is correct: it is common practice today for MSAs to reject
message postings where no relationship exists with the MUA (or
user, or MUA host).   RFC 4409 requires that behavior for
Submission servers.   That paragraph goes on to say "...an MDA
can choose to reject all mail to recipients for which that MDA
has no arrangement to perform delivery."   Certainly that is
true, since it has been a firm requirement since before RFC 821
was published (and arguably going back to the days of FTP-based
netmail).  Now, I think the point the authors are trying to make
depends on a very narrow and precise definition of "reject".
But that term is not defined appropriately in this document: as
far as I know, its only definition and consistent use in a
standards-track document (specification or candidate) for
Internet email is in 2821bis (draft-klensin-rfc2821bis, version
-03 and later).

Interestingly, the "Delivery Authorization" subsection of
Section 4.1 says "MUST NOT accept..." which avoids the problem
of the definition of "reject".  But see (6) below.

As a related editorial quibble, the language of the introductory
paragraph of Section 3 implies that initial submission via SMTP
is never authenticated.  That is simply not correct (and this
document says so in Section 5). 

(3) The provisions of the first paragraph of Section 3.2 seem
odd to me.  If we believe that authentication and authorization
of the submission MUA are important (which is what 3.1 appears
to say, with MUST-level requirements), then saying that MSAs
"SHOULD" require authentication on SMTP-based submissions
appears to provide a way to evade that requirement.   I can see
good reasons for  this provision, including conforming to actual
current practice, but it needs, IMO, considerably more
explanation and rationale of when it it is acceptable to violate
the "SHOULD".

(4) The first paragraph of Section 4 seems to be unnecessarily
obscure to me, especially if it is expected to be read by
someone who is not intimately aware of email protocols,
terminology, and the discussions of the last few years.  As the
most glaring example, what is the definition of a "mass-effect
email problem"?

The Section 4 recommendation to use Submit on port 587 rather
than SMTP (on port 25) for initial submission is wonderful, and
consistent with the recommendations in Section 3 and elsewhere.
But there is ultimately nothing magic about Port 587 other than
that most providers who are providing crude blocks on port 25
haven't awakened to Port 587 yet _and_ that Submit requires
authentication and SMTP does not (see comment (3) above).

(5) A MUST NOT requirement on blocking Submit (Section 4.1) is a
bit dubious at this point.  Again, I am sympathetic to the
reasons, but there are presumably still implementations of RFC
2476 out there that do not require authentication.   An access
provider has no way to be guaranteed that all servers on port
587 authenticate and authenticate adequately (i.e., there is no
trust relationship between an access provider and an arbitrary
port 587 server at all).  So, if the access provider believes
that blocking outbound port 25 is an important anti-spam
measure, then blocking port 587 traffic to an open relay on that
port is equally rational.  I think that demotes this requirement
to a SHOULD, with as strong an explanation as the authors deem
appropriate.

(6) Section 4.1 "Delivery Authorization".  This seemingly mild
and reasonable statement about accepting mail interacts with an
ongoing debate in the rfc2821bis effort and elsewhere.  At least
as I read it, it directly contracts text in 2821 which permits
an MTA to "accept" (i.e., respond with 2yz codes) messages for
any address, evaluate the address after acceptance, and then
"bounce" (generate an NDN and return all or part of the message)
if the address is unauthorized or undeliverable.   As we have
discovered with 2821bis, eliminating that option requires
consideration of some fairly complex issues with the email
architecture.  On the other hand, if the MDA could assume that
the other recommendations and requirements of this document had
been followed, the issues with "bouncing" messages would largely
disappear and this requirement would apparently become a trivial
restatement of the 821-and-earlier requirement that a server
accepting a message take the transfer of responsibility
seriously.

(7) Section 5 refers to SMTP AUTH or TLS as if they are
sufficient solutions to the issues and requirements of this
document.  Fortunately or unfortunately, either can be used in
ways that does not satisfy these requirements.  In particular
RFC 3207 TLS can be used to provide privacy protection without
any meaningful client authentication at all.  I believe that our
norms require that those issues be discussed either in this
section or in Security Considerations if these techniques are to
be given as examples.

thanks,
    john

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Jun 2007 15:53:07 +0100

On Thu, 21 Jun 2007, John C Klensin wrote:
>
> (2) Section 3.1 contains a MUST requirement for availability of the
> message submission port (RFC 4409).  While I am a firm believer in RFC
> 4409 and look forward to the point at which we can put out a document
> that deprecates the use of SMTP (RFC 2821) for message submission by
> clients that do not support full SMTP services (for many more reasons
> than spam mitigation), we aren't there yet, and a MUST requirement
> definitely does not represent current practice.

It does represent *best* current practice, and I think it it reasonable to
say that a site is not conformant to draft-hutzler-spamops if they don't
support RFC 4409. I don't think this document is trying to say that all
sites will have to adhere to all the MUSTard, just that they can't claim
to be following best current practice if they don't.

> It seems to me that the provision that the tracing requirement of
> "Submission Accountability after Submission" can be satisfied by
> examining header information requires a comment, either inline or in
> Security Considerations, about the ease or difficulty of spoofing that
> information.

It says "based on" which I read to mean "in combination with logs", and I
think the comments about how long it is possible to trace a message refer
to log rotation. In which case spoofing isn't something to worry about.
However I don't know why it is so vague about mechanisms.

> The Section 4 recommendation to use Submit on port 587 rather than SMTP
> (on port 25) for initial submission is wonderful, and consistent with
> the recommendations in Section 3 and elsewhere. But there is ultimately
> nothing magic about Port 587 other than that most providers who are
> providing crude blocks on port 25 haven't awakened to Port 587 yet _and_
> that Submit requires authentication and SMTP does not (see comment (3)
> above).

It might not be magic, but the authentication means that the operator of
the MSA has a relationship with the sender and therefore has meaningful
responsibility for and control over any email - contrast port 25 where
there is no authentication and the operator of the MTA is a victim who
has no reliable way of telling good from bad traffic.

> (5) A MUST NOT requirement on blocking Submit (Section 4.1) is a bit
> dubious at this point.  Again, I am sympathetic to the reasons, but
> there are presumably still implementations of RFC 2476 out there that do
> not require authentication.  An access provider has no way to be
> guaranteed that all servers on port 587 authenticate and authenticate
> adequately (i.e., there is no trust relationship between an access
> provider and an arbitrary port 587 server at all).  So, if the access
> provider believes that blocking outbound port 25 is an important
> anti-spam measure, then blocking port 587 traffic to an open relay on
> that port is equally rational.  I think that demotes this requirement to
> a SHOULD, with as strong an explanation as the authors deem appropriate.

No, because an open relay is the responsibility of its operators, not the
responsibility of every access provider on the net. You need to
distinguish direct attacks from indirect attacks.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WIGHT: SOUTHERLY VEERING WESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST IN WEST.
MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Jun 2007 08:40:33 -0700

> to be following best current practice if they don't.

Not sure whether John continues to confuse statistics with quality -- that is, 
how much sites currently support port 587, versus the anti-abuse operation 
community's view of whether supporting it is a good idea -- but as you note, 
supporting 587 most certainly *is* considered advisable by the anti-abuse 
community.  The simple act of separating posting from delivery streams 
improves the ability to make posting activities more accountable.

As for the semantics of a MUST in an IETF document, it is interesting that 
confusion persists between "everyone everywhere must always do the MUSTs that 
the document dictates" versus "anyone claiming to conform to this document 
must always do the MUSTS that the document dictates."  As you note, the 
semantis of an IETF document are the latter, not the former.

> However I don't know why it is so vague about mechanisms.

In developing the document, we tried to keep away from anything that was 
controversial, in preference to getting a document that could be widely 
accepted.  With respect to discussing the details of any particular mechanism, 
there is simply too much variance in the operations community.

It would have been too easy to try to make the document be a primer on email 
operations; we chose not to do that. Since Received header field analysis is 
tricky business, any meaningful discussion of the process would have required 
extensive pedagogy about email basics.

> has no reliable way of telling good from bad traffic.

Nicely said.  And, of course, correct.

> distinguish direct attacks from indirect attacks.

NS.  A, oc, c...

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Jun 2007 13:00:56 -0400

--On Thursday, 21 June, 2007 15:53 +0100 Tony Finch
<[email-masked]> wrote:

>> (2) Section 3.1 contains a MUST requirement for availability
>> of the message submission port (RFC 4409).  While I am a firm
>> believer in RFC 4409 and look forward to the point at which
>> we can put out a document that deprecates the use of SMTP
>> (RFC 2821) for message submission by clients that do not
>> support full SMTP services (for many more reasons than spam
>> mitigation), we aren't there yet, and a MUST requirement
> It does represent *best* current practice, and I think it it
> reasonable to say that a site is not conformant to
> draft-hutzler-spamops if they don't support RFC 4409. I don't
> think this document is trying to say that all sites will have
> to adhere to all the MUSTard, just that they can't claim to be
> following best current practice if they don't.
>...

Tony (and Dave)...

Please reread my introductory note.  I think all of the
recommendations are fine.  My problems are with classifications
and language only, with "language" including a few things where
I think the document is a little more vague than it should be,
especially around Security Considerations.   I'm also nervous
when you respond to a remark by giving your rather specific
interpretation of terms like "based on": not because I disagree,
but because the presumed audience for a document like this
presumably includes those who don't already know the answers and
the IETF's thinking. 

I don't think repeating all of this helps: if the IESG concludes
that there is consensus to publish this, as is and as a BCP,
that is how it goes.  I just disagree with doing that and felt a
need to express that opinion and explain it.

Without going through your comments point by point, which I
don't think is useful in this case, let me summarize my reaction
to all of them with "ok, that is fine, why doesn't the document
just say that".   Again, my problems are about language and
specification style/ level/ completeness, not about the
recommendations.

But, as an illustration of my problem, let's compare the above
with the later text about Submission servers (MSAs) supporting
both Submit and SMTP.  I suggest (and I hope my comments made
clear) that the *best* practice there is for the MSA operator to
require that all MUAs that intend to be its client support
Submit -- the port and the authentication -- and hence that port
25 traffic be prohibited entirely or, at least, supported with
the same level of authentication that particular MSA would
require for Submit if the MUA were using that port.  But the
document wraps SHOULD language around that case.  If the
difference is recognition of existing practice and the fact that
a few MUAs haven't caught up, that is fine, but it is somewhat
inconsistent, IMO, with your "*best* current..." reasoning above.

I've also got some problems with conformance language and a BCP
like this (one that effectively profiles existing protocols).
It feels to me that BCPs should be largely descriptive: "this is
the best current practice" and not "to conform to the norm set
by this document, you MUST do this, that, and the other thing".
I realize I am probably in the minority of the IETF about
considering that distinction useful.

Finally, I've got a problem with conformance scope that may be a
general issue where applied to a BCP.  If the intent is that
someone either conforms to the statements of this document or
they are not conformant to this particular document (as your
note suggests), I have no problem.  But, absent some very
specific language in the document _and_ clear instructions to
the RFC Editor that this is not permitted to share a BCP number
with anything, it seems clear to me that failure to fully
conform to this document (i.e., obey all of the SHOULDs and
MUSTs) will be construed a failure to use best practices for
Internet Mail generally, including in environments and for
purposes for which this document may not be applicable.   It
doesn't contain a discussion of those cases, which is probably
fine, but encouraging overly-broad interpretations of expected
conformance scope, even by omission, seems like a bad idea to me.

Again, just my opinion.

     john

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Jun 2007 18:16:17 +0100

On Thu, 21 Jun 2007, John C Klensin wrote:
>
> But, as an illustration of my problem, let's compare the above with the
> later text about Submission servers (MSAs) supporting both Submit and
> SMTP.  I suggest (and I hope my comments made clear) that the *best*
> practice there is for the MSA operator to require that all MUAs that
> intend to be its client support Submit -- the port and the
> authentication -- and hence that port 25 traffic be prohibited entirely
> or, at least, supported with the same level of authentication that
> particular MSA would require for Submit if the MUA were using that port.
> But the document wraps SHOULD language around that case.  If the
> difference is recognition of existing practice and the fact that a few
> MUAs haven't caught up, that is fine, but it is somewhat inconsistent,
> IMO, with your "*best* current..." reasoning above.

It's not inconsistent: you can't ignore the limits on what is achievable.
You seem to be suggesting that "current practice" means what operators
actually do (including the morons and dinosaurs) and "best practice" means
the fantasy ideal world that we strive towards. Obviously a document
describing the former doesn't move us forwards, and one describing the
latter is useless for operators who are constrained by reality. I think
it's unreasonable to argue against the document on the grounds that it
tries to strike a reasonable middle path.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
DOVER WIGHT: SOUTHERLY 3 OR 4, VEERING WESTERLY 4 OR 5. MODERATE, OCCASIONALLY
ROUGH IN WEST WIGHT. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Jun 2007 13:40:17 -0400

--On Thursday, 21 June, 2007 18:16 +0100 Tony Finch
<[email-masked]> wrote:

> It's not inconsistent: you can't ignore the limits on what is
> achievable. You seem to be suggesting that "current practice"
> means what operators actually do (including the morons and
> dinosaurs) and "best practice" means the fantasy ideal world
> that we strive towards. Obviously a document describing the
> former doesn't move us forwards, and one describing the latter
> is useless for operators who are constrained by reality. I
> think it's unreasonable to argue against the document on the
> grounds that it tries to strike a reasonable middle path.

Hmm.  Since a few providers, at least one of them quite large,
have already imposed "find an MUA that supports authentication
or go elsewhere" requirements without being driven out of the
marketplace or even suffering any noticeable pain, I didn't
consider the requirement to be unachievable, unrealistic, or a
fantasy.  YMMD, of course.

     john

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Jun 2007 19:08:28 +0100

> fantasy.  YMMD, of course.

I run a university email system not a free webmail service, so I have to
be rather more accommodating. Still, although all routes in to our main
email service (Hermes) are encrypted and authenticated, we still have a
trad smarthost which is mainly used by departmental MTAs but also by MUAs
when smtp.hermes is not appropriate (e.g. visitors who don't have a Hermes
account).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL: NORTHERLY 4 OR 5, OCCASIONALLY 6 AT FIRST. MODERATE OR ROUGH.
SHOWERS. GOOD.

---

From: Chris Newman <[email-masked]>
Date: Fri, 22 Jun 2007 17:48:47 -0700

My last call comment as a technical contributor (apologies for the lateness):

Overall, this is a very important document which I support.

I'm not fond of the current title because I believe it will cause the document 
to be ignored by the people who most need to read it.  I suggest:

   "Operational Requirements for Email Submission"

The best way to improve this document otherwise would be by deleting text from 
the document and trimming it down to just the best practice requirements and 
recommendations.  Move the descriptive text about architecture and how the 
email system works somewhere else (e.g. Dave's email architecture document).

Operators will run MSAs on port 25 if they need to, so it's unnecessary to make 
a normative recommendation about that.  At some point it may cease to be useful 
to run an MSA on port 25 so requiring an update to this document when that 
happens is short-sighted.

                - Chris

The IESG wrote on 6/6/07 10:32 -0400:

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-06-20. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> Note that this is a second run of the Last Call. The first Last Call
> happened in 2005, and the current version tried to address all the
> comments received then. Taking into account the amount of time since the
> first Last Call the Area Director and the editors decided to run again a
> two weeks Last Call.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-hutzler-spamops-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11673
> &rfc_flag=0
>
>
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>