Subject: [yam] WGLC: draft-ietf-yam-rfc4409bis-00

From: S Moonesamy <[email-masked]>
Date: Thu, 26 May 2011 09:56:14 -0700

Hello,

This message starts a Working Group Last Call for "Message Submission 
for Mail" (draft-ietf-yam-rfc4409bis-00).  The I-D can be accessed at
http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-00

This Working Group Last Call starts on Thursday 26th May and will end 
on Thursday 9th July.  Please review the I-D and send comments to the 
YAM mailing list.

Regards,
S. Moonesamy
YAM co-chair

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 May 2011 14:10:25 -0400

--On Thursday, May 26, 2011 09:56 -0700 S Moonesamy
<[email-masked]> wrote:

> Hello,
> 
> This message starts a Working Group Last Call for "Message
> Submission for Mail" (draft-ietf-yam-rfc4409bis-00).  The I-D
> can be accessed at
> This Working Group Last Call starts on Thursday 26th May and
> will end on Thursday 9th July.  Please review the I-D and send
> comments to the YAM mailing list.

Did you mean "9th June"?   9 July is not on a Thursday and a six
or seven week WG LC would seem excessive to me.

   john

---

From: S Moonesamy <[email-masked]>
Date: Thu, 26 May 2011 11:24:28 -0700

>or seven week WG LC would seem excessive to me.

Thanks for pointing out that mistake.  It's a two-week WGLC.  This is 
a correction to the message posted at 
http://www.ietf.org/mail-archive/web/yam/current/msg00612.html

The Working Group Last Call on draft-ietf-yam-rfc4409bis-00 starts on 
Thursday 26th May and will end on Thursday 9th June.

Regards,
S. Moonesamy
YAM co-chair

---

From: Derek Diget <[email-masked]>
Date: Thu, 26 May 2011 16:58:10 -0400 (EDT)

On May 26, 2011 at 09:56 -0700, S Moonesamy wrote:
=>This message starts a Working Group Last Call for "Message Submission for
=>Mail" (draft-ietf-yam-rfc4409bis-00).  The I-D can be accessed at
=>http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-00

Raising hand timidly.....

1) Is it possible to insert a blank line between data rows in Table 1?  
I find it hard to read with each column having something wrapped at some 
point.  For example...

  | PIPELINING       | Pipelining       |   SHOULD  | [PIPELINING]    |
  |                  |                  |           |                 |
  | ENHANCEDSTATUSCO | Enhanced Status  |   SHOULD  | [CODES-EXTENSIO |
  | DES              | Codes            |           | N]              |
  |                  |                  |           |                 |
  | ETRN             | Extended Turn    |  MUST NOT | [ETRN]          |
  |                  |                  |           |                 |
  | ...              | Extended Codes   |   SHOULD  | [SMTP-CODES]    |
  |                  |                  |           |                 |
  | DSN              | Delivery Status  |   SHOULD  | [DSN]           |
  |                  | Notification     |           |                 |
  |                  |                  |           |                 |

Maybe since the "Name" column has just one entry that wraps 
(ENHANCEDSTATUSCODES), it could be made one character narrower so that 
the "Submission" column header wouldn't wrap?  (I think that you could 
even make it (Name) a total of 3 characters narrower which would also 
allow the "Reference" column to grow by two and not wrap a cell.)

2) I am not sure if a mention to RFC 6186 - Use of SRV Records for 
Locating Email Submission/Access Services and its section 3.1 
would be appropriate in this RFC?  Say, by adding something like the 
following to section 3.1:

   A site [can|SHOULD?] publish the SRV record that provides a client 
   the site's preferred submission port [RFC6186].

-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 May 2011 17:25:51 -0400

--On Thursday, May 26, 2011 16:58 -0400 Derek Diget
<[email-masked]> wrote:

> =>This message starts a Working Group Last Call for "Message
> Submission for =>Mail" (draft-ietf-yam-rfc4409bis-00).  The
> I-D can be accessed at
> 1) Is it possible to insert a blank line between data rows in
> Table 1?   I find it hard to read with each column having
> something wrapped at some  point.  For example...
> 
>   | PIPELINING       | Pipelining       |   SHOULD  |
>...
> (ENHANCEDSTATUSCODES), it could be made one character narrower
> so that  the "Submission" column header wouldn't wrap?  (I
> think that you could  even make it (Name) a total of 3
> characters narrower which would also  allow the "Reference"
> column to grow by two and not wrap a cell.)

Derek,

Writing as co-author and, for this iteration, lead pen-holder,
I've got a longstanding bias that says, approximately, that the
RFC Editor staff is extremely competent, does their jobs well
when we let them, and does final reformatting of documents
anyway.  For some reason, I seem to feel more strongly about
that over time.

One of the implications of that principle is that I have not,
for example, tried to fuss with column widths to improve
readability, much less spent time on vertical formatting (blank
lines or ruled lines between rows).  That level of fussing
(e.g., making one column a character or three narrower or trying
to insert blank lines when there doesn't seem to be a directive
for that and the DTD doesn't permit <vspace> elements within a
<texttable> is not how I think I, or other IETF authors, should
be spending our time... and is easier to do in nroff anyway.

I've assumed that the RFC Editor would just straighten these
things out and intended to put a note into the XML asking
specifically that they take a look at it.  I've now inserted
that note as a comment in the working copy.  If you, or others,
think that a more explicit note (in a comment that shows up in
the ASCII text) is needed, I'm happy to convert the comment, but
I can't imagine its making a difference in the long run.

> 2) I am not sure if a mention to RFC 6186 - Use of SRV Records
> for  Locating Email Submission/Access Services and its section
> 3.1  would be appropriate in this RFC?  Say, by adding
> something like the  following to section 3.1:
> 
>    A site [can|SHOULD?] publish the SRV record that provides a
> client     the site's preferred submission port [RFC6186].

Speaking as editor, I don't have a strong preference and will
put in whatever text the WG prefers.  However, please note that
4409bis is a candidate for full Standard and that your text
above, even with MAY, creates a normative reference or close to
it.  Perhaps more important, while I haven't been looking and
might not have seen it, I haven't seen a lot of evidence of wide
adoption of 6186.  I'd be a lot more comfortable with the idea
of incorporating that sort of text if someone felt like
compiling and posting an implementation report on 6186 (not a
bad idea in its own right).

   john

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 May 2011 17:37:20 +0200

On 26/May/11 18:56, S Moonesamy wrote:
> Please review the I-D and send comments to the YAM mailing list.

Does it make any sense to add an MSA-specific header field?

Hm...  RFC 5451 provides an Authentication-Results entry to convey
SMTP-AUTH results --not necessarily SUBMISSION.  It is exemplified as

  Authentication-Results: example.com;
     auth=pass (cram-md5) smtp.auth=[email-masked];

RFC 4409, as well as 'bis', generically say that "The MSA MAY
(digitally) sign or otherwise add authentication information to the
message."  However, lines like the one exemplified above would reveal
the sender's login id, which the MSA may want to hide according to
(I-D, section 8.8):

  For example, a site may prefer to rewrite 'JRU' as
  'J.Random.User' in order to hide login names

Thus, if at all, it may be worth mentioning that the relevant
/propspec/ may be omitted for the same reason.  That is, e.g.,

  Authentication-Results: example.com;
     auth=pass (details omitted as precautionary measure);

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 May 2011 12:59:34 -0400

--On Friday, May 27, 2011 17:37 +0200 Alessandro Vesely
<[email-masked]> wrote:

> Hm...  RFC 5451 provides an Authentication-Results entry to
> convey SMTP-AUTH results --not necessarily SUBMISSION.  It is
> exemplified as
> 

Folks, let's remember the YAM (and Full Standard) constraints.
Adding new fields or other features -- required or even
optional-- sets us back to Proposed.

>      auth=pass (details omitted as precautionary measure);

Because "Authentication-Results:" is not a 4409 field, it seems
to me that this is a problem that needs to be addressed in
5451bis or elsewhere, not here.

    john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 May 2011 10:07:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Friday, May 27, 2011 10:00 AM
> To: Alessandro Vesely; [email-masked]
> Subject: Re: [yam] WGLC: draft-ietf-yam-rfc4409bis-00
> 

I agree, there's no need to recycle 4409 for this.  Section 8 lists changes that have been observed as useful in the past, but don't establish SHOULDs or MUSTs around any of them (except Message-Id, which makes sense anyway since 5322 SHOULDs it), so it's largely advice and not normative.

If there are sites that actually do this, I'd be happy to support the work of a 5451bis that updates 5451 in this way, and perhaps updates 4409bis as well.  If it's just an idea, though, we can queue it up for later, such as whenever there are enough errata to fix it up.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 27 May 2011 11:21:21 -0700

>Raising hand timidly.....

I appreciate that Deret Diget took the time to review 
draft-ietf-yam-rfc4409bis-00.  I would like to encourage other 
working group participants to review the document and post a message 
about it.  Don't be timid; all comments are welcome, whether you are 
a new participant or not.

The work done in this working group is covered by a charter ( 
http://www.ietf.org/dyn/wg/charter/yam-charter ).  The charter 
discusses about changes to the specifications under review.  I gather 
that the working group fully understands that the intention is to 
publish draft-ietf-yam-rfc4409bis as an Internet Standard and not as 
a Proposed Standard.

Regards,
S. Moonesamy
YAM co-chair

---

From: "John Levine" <[email-masked]>
Date: 27 May 2011 20:25:55 -0000

The description of the protocol is fine.  The dicta, less so.

Setion 3.2 says:

  If an MSA is not able to determine a return path to the submitting
  user, from a valid MAIL FROM, a valid source IP address, or based on
  authenticated identity, then the MSA SHOULD immediately reject the
  message. A message can be immediately rejected by returning a 550
  code to the MAIL command.

I think I understand the motivation, but that just seems wrong.  I
have lots of web scripts that submit mail using various bounce
addresses, and there's no way to tell whose script it was without
looking at the web logs.  My MUAs put a variety of bounce addresses on
the mail they send, some in domains local to the host with the
submission server, some not.  So what?

Suggest deleting this pp and fixing the first sentence two pp down
that refers to it.

The NOTE: at the end of the section suffers from our endemic bad UI
advice syndrome:

  To properly handle delayed bounces, the client MUA needs to maintain
  a queue of messages it has submitted, and match bounces to them.

Again, that just seems wrong.  Humans can and do look at bounces and
do whatever they do with no MUA help.  Suggest deleting the sentence.

Section 3.3, third pp says:

  IP address restrictions are very widely implemented, but do not
  allow for travelers and similar situations, and can be easily
  spoofed unless all transport paths between the MUA and MSA are
  trustworthy.

Spoofing the IP on a TCP session is very difficult, and if an attacker
can do that, you've got worse problems than faked mail.

The following paragraph mentions IPsec, the pp after that
pop-before-smtp.  Speaking as the inventor of pop-before-smtp, I think
it's time to kill that dinosaur.  I'd suggest replacing all three PP
with something like this:

  IP address restrictions are widely used, both fixed IP ranges of
  known networks, and IP addresses recently validated for use by other
  protocols such as POP [POP3].  Secure IP [IPSEC] and other
  encrypted and authenticated tunneling techniques can be used to
  provide protection against eavesdropping and traffic analysis.

Saurian note: I've also done IMAP-before-SMTP.  Please don't document it.

Section 6,1 refers to "submission rights." They're not defined anywhere.
What are they?  The phrase appears in RFCs 2476 and 4409 but not in any
other RFC as far as I can tell.

Section 6.4 describes special case handling of mail addressed to
postmaster.  Does anyone actually do that?  If not, perhaps move it to
a deprecated appendix.

The NOTE: in section 8 appears to contradict the last paragraph in 4.2.
Is it OK to expand single-component domains or not?

Section 8.7 makes resolving CNAMES optional.  I thought it was still
officially mandatory.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 27 May 2011 13:31:05 -0700 (PDT)

+1

				Ned

> _______________________________________________
> yam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yam

---

From: Ned Freed <[email-masked]>
Date: Fri, 27 May 2011 13:53:58 -0700 (PDT)

> submission server, some not.  So what?

I'm a little unclear on why you think the requirement to check the validity of
the MAIL FROM would be a problem here. Surely the bounce addresses you're using
are at least superficially valid? THat's all the text is saying needs to be
checked; I don't see it as requiring access restriction or address locality
or anyting along those lines.

> Suggest deleting this pp and fixing the first sentence two pp down

I don't think this is a major point, but OTOH I fail to see any harm in
the text that's there now.

> do whatever they do with no MUA help.  Suggest deleting the sentence.

Strongly disagree. Yes, people handle bounce mnaully all the time, and they
often handling them badly. MUA correlation of bounces with original
messages addresses that and IMO we should encourage it, which is what this
section does.

> can do that, you've got worse problems than faked mail.

THe difficulty of IP address spoofing varies tremendously with network geometry
and location. The nature of the address you're attempting to spoof can also be
a factor.

Sitting here in my office connected to the company network only, I would have a
very difficult time indeed spoofing an IP to your email server. But things
would be very different if I were able to access your LAN and able to do ARP
spoofing. Or if I could splice in to your DSL connection. Here the key
difference is whether or not I'm able to access the network connection
or not. In other words, it boils down to whether or not the path is 
trustworthy, which is exactly the point the document makes.

I see no problem with the present text and I think it should be retained.

>   provide protection against eavesdropping and traffic analysis.

Question: Aside from the VPN case, how much IPsec usage for securing SMTP have
you seen? I don't think I can come up with even one example. So, while I don't
really object to changing this text to deemphazie the POP-before-SMTP hack, I
don't see how retaining the idea that using IPSec for this is helpful. And i
think removing the text about spoofing would be a mistake.

> Saurian note: I've also done IMAP-before-SMTP.  Please don't document it.

Agreed.

> other RFC as far as I can tell.

Yes, the concept should be described.

> postmaster.  Does anyone actually do that?  If not, perhaps move it to

We certainly support doing it; whether or not anyone actually uses this
capability is anyone's guess. I don't recall ever seeing an access control
setup that allowed sending to postmaster only when in an unauthenticted
state.

I certainly wouldn't object to deprecacing this.

> Is it OK to expand single-component domains or not?

The restriction in 4.2 is talking about multi-compponent but not fully
qualified domains, so I don't see the conflict.

I will say that the advice about allowing foo.sales or bar.us or whatever
is sound but likely to fall on deaf ears.

> Section 8.7 makes resolving CNAMES optional.  I thought it was still

Actually it's a fairly new requirement, but yes, it is now a requirement,
so this needs to be fixed.

---

From: "John R Levine" <[email-masked]>
Date: 27 May 2011 17:51:45 -0400

A lot of this stuff is advice that doubtless seemed reasonable in 1998, 
but not so much now.

>>   code to the MAIL command. ...

> the MAIL FROM would be a problem here.

But that's not what it says.  By my reading, if the MSA can't divine "a 
return path to the submitting user", it's supposed to reject the mail. 
As in my example, what if the submission is a web script that happens to 
be sending a message with a null return path, something that the following 
pp specifically says is OK, or that returns bounces to some other server 
which is configured to handle them, but the MSA doesn't happen to know 
about.  What's "a return path to the submitting user"?  Why should an MSA 
care?

That's not the same as syntax-checking any return path that the client 
provides, which I agree is entirely reasonable, and is implicitly covered 
in sec 4.2 and explicitly in 5.1.

> messages addresses that and IMO we should encourage it, which is what this

I realize this advice has been in SUBMIT RFCs since 1998, but just out of 
curiosity, what MUAs do that?  I've never seen one.  If after 13 years 
nobody's taken the advice, perhaps it's time to stop.

> and location. The nature of the address you're attempting to spoof can also be

Right.  But if they're on your LAN and sniffing your traffic, like I said, 
you've got worse problems than spoofed mail.  To me this implies that IP 
spoofing is easy in general, like spoofing a From: address, but it's not.

> you seen?

I've never used IPsec at all, being an ssh kind of guy.  How about redoing 
the advice to say something general about using session security 
appropriate to the (in)security of the connection?

> qualified domains, so I don't see the conflict.

Sec 4.2 says that adding a domain to a single component doman is OK, 
multicompoment domain isn't.  Sec 8 says:

   For example, indiscriminately appending a domain to an address or element
   that lacks one typically results in more broken addresses. An
   unqualified  address must be verified to be a valid local part in the
   domain before the domain can be safely added.

Which now says that adding domains to single component domains isn't 
always a great idea either.  It would be nice if they agreed.

Section 8 also says:

   An unqualified address must be verified to be a valid local part in the
   domain before the domain can be safely added.

Again, I see the point but in the not uncommon case that the MSA doesn't 
have access to the full table of local addresses, the worst thing that 
will happen is a bounce, which may be annoying but doesn't seem "unsafe" 
to me.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 May 2011 21:13:22 -0400

--On Friday, May 27, 2011 17:51 -0400 John R Levine
<[email-masked]> wrote:

> A lot of this stuff is advice that doubtless seemed reasonable
> in 1998, but not so much now.
>...

John,

I will do whatever the WG likes but a few observations:

* We went through a long and painful process to get the
pre-evaluation document to some sort of consensus in the WG (not
that long ago).  Because of the way YAM is supposed to work, I'm
a little hesitant to start making major "we want to reevaluate
how the protocol works and what advice is given" changes to
things that were in the existing document (here 4409 for five
years now), that have drawn no errata, and that were neither in
the pre-evaluation document nor identified and required by some
IETF protocol work elsewhere (in this case, the EAI discussions
that concluded the 4409 wasn't clear enough about the ability of
an MSA to change/ adapt character encodings).

* 4409 (and 2476) were designed, fairly explicitly, around a
fairly traditional MUA submission model: software residing on a
client machine communicating with a submission server over SMTP
(I refer to this as "client-side MUA" below).  It does not
address, e.g., the even older model of a user logging remotely
into a machine with server capabilities (such as the ability to
maintain message queues for transmission) and accessing MUA
software that prepares messages and then hands them off to the
SMTP client, usually via something we would now call an API or
IPC function.  Whether, for example, such a client-side MUA
maintains tables by which outgoing messages can be correlated
with error messages and replies, it is a property of the
environments that a user is rarely going to see an error reply
or response code except through the intermediation of that MUA.

I have far less experience than I assume you and Ned do with
regard to web-based mail clients but I imagine them to have some
of the properties of the historic server-based NUA as well as
some of the properties of the newer MUA on a client machine that
communicates with an MSA as above.  

If the things you have encountered with your web scripts and web
clients are different from the advice that the WG (in the
pre-evaluation document) and Ned's experience indicate that we
should probably still be giving classical client-side MUAs, it
suggests to me that it would be far better to prepare and sort
out a "message submission for web clients, scripts, and
services" document, rather than trying to revise and patch the
4409bis discussion on short notice, during WG Last Call, and in
a relatively inactive WG. I don't have an opinion, at least yet,
as to whether that document would be a slightly different
protocol spec, an update to certain aspects of 4409bis, or an
Applicability Statement discussing the implications of 4409bis
to particular environments and situations.

I think that, if there were a commitment to developing such a
document, it would make sense to modify 4409bis to make its
assumption of the client-side MUA model clear and to indicate
that subsequent documents might describe other kinds of
submission behavior.

   best,
    john

p.s. A general observation about the state of YAM...  To me,
4409bis is not only worth doing in and of itself, it is a bit of
a test case as to whether we can actually open up documents and
clean them up as needed to advance them in the Standard Track
(or just clean them up) without taking the opportunity to
reexamine the protocol, various bits of advice, etc.  If we
cannot do that with 4409bis, I think the WG will need to look
very carefully at the value proposition associated with other
specs, especially if a two-step standards process is adopted and
essentially just redefines all of the YAM document repertoire
into full standards.

---

From: "John R Levine" <[email-masked]>
Date: 27 May 2011 22:17:38 -0400

> I will do whatever the WG likes but a few observations:

In case it wasn't obvious, nothing I'm suggesting is supposed to change 
the bits on the wire.  SUBMIT works fine, but the way people actually use 
it doesn't match the dicta in 4409 very well, even for clients that are 
MUAs driven by people, e.g. MSAs don't generally verify local addreses 
before adding the local domain, MUAs don't match up DSNs with archived 
outgoing mail.

> a relatively inactive WG.

That would be possible, or we could do a BCP or app note saying how people 
really use it.

Regards,

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 May 2011 01:11:26 -0700

Hi John,

>essentially just redefines all of the YAM document repertoire

This working group has been inactive since the end of last year.  Due 
to circumstances beyond the control of YAM WG, it has known a 
difficult start.  YAM was formed in May 2009.  The WG has only 
produced one Internet Standard up to now.  WG participants may have 
different ideas of what fits within the scope of changes for an 
Internet Standard or what's an Internet Standard meant to be.  I'll 
highlight a sentence from the YAM Charter:

  "If an existing protocol implementation is conforming to the Draft Standard
   version of the protocol specification, it must also be conforming to the
   resulting Full Standard version."

The YAM WG adopted a two-stage process where it does any evaluation 
which identifies the list of changes first 
(draft-ietf-yam-4409bis-submit-pre-evaluation-00).  The next step is 
for the editors of 4409bis to incorporate these changes in a draft 
(draft-ietf-yam-rfc4409bis).  There are some new changes that have 
been suggested during this second step.  I suggest leaving the 
discussion about those changes open for a few days.  I'll post a 
summary of the discussion after that.  Let's see whether we can get 
some form of agreement on what fits within the scope of changes 
instead of the WG Chairs taking a heavy-handed approach.  Please note 
that this is not an invitation to rewrite the protocol. :-)

Regards,
S. Moonesamy

---

From: SM <[email-masked]>
Date: Sat, 28 May 2011 10:19:50 -0700

Hi John,
>submission server, some not.  So what?

I read the entire Section 3.2 again for context.  There are cases 
when the text you quoted may be applicable.  The paragraph is about 
"Message Rejection and Bouncing".  Basically, it says that it is 
better for the MSA to reject a message instead of bouncing it.  As 
this is done close to the sender, problems can be resolved more easily.

>do whatever they do with no MUA help.  Suggest deleting the sentence.

The user usually call the help desk or ignore these bounces.  If a 
MUA were to follow that advice, the user could be informed about 
whether the message that is flagged as "sent" was actually 
delivered.  Unfortunately, "many contemporary MUAs do not have this 
capability".

>with something like this:

Some people are still doing pop-before-smtp "authentication".  I 
advise people to use SMTP-AUTH which is covered by the second 
paragraph of Section 3.3.  One of the changes to the document is the 
normative reference to RFC 4954.

>other RFC as far as I can tell.

As I read it, the text mentions the reply code and the enhanced 
status code to use in such cases.  "Submission rights" might, for 
example, be viewed as which addresses are allowed in the "MAIL 
FROM".  I am not sure whether the text is a remnant from Section 3.4 
of RFC 2476.

>postmaster.  Does anyone actually do that?  If not, perhaps move it to

My litmus test would be: "is this a problem".  I suggest leaving it in.

>Is it OK to expand single-component domains or not?

I'll apply the same test as above.

>Section 8.7 makes resolving CNAMES optional.  I thought it was still

Section 8.7 goes with Section 8.8 (header rewriting).  The decision 
for address fields of the header is subject to local policy.  I'm 
open on this one.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 28 May 2011 10:31:15 -0700

Hi Derek,
>    the site's preferred submission port [RFC6186].

RFC 6186 is a Proposed Standard and it only a few months old.  It may 
be premature to introduce such a requirement at this maturity 
level.  I would wait for an interoperability report at the very least.

I don't know whether you will find the message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg63012.html useful. :-)

Regards,
-sm

---

From: "John R Levine" <[email-masked]>
Date: 28 May 2011 14:00:52 -0400

> I read the entire Section 3.2 again for context.  There are cases when the 
> text you quoted may be applicable.  The paragraph is about "Message Rejection 
> and Bouncing".  Basically, it says that it is better for the MSA to reject a 
> message instead of bouncing it.  As this is done close to the sender, 
> problems can be resolved more easily.

That part is fine.  What seems wrong is the advice that the MSA should 
reject the message "if it is not able to determine a return path to the 
submitting user."  My MSAs have no idea what is a return path to the 
submitting user, nor whether a return path offered by a client has any 
connection to that client.  They check the bounce address syntax, put some 
stuff in the Received: header that will let me identify the AUTH or login 
user if need be, and go on.

This text is unchanged since 2476, so I must admit that even though it 
makes no sense, it doesn't seem to have caused much damage.

> The user usually call the help desk or ignore these bounces.  If a MUA were 
> to follow that advice, the user could be informed about whether the message 
> that is flagged as "sent" was actually delivered.  Unfortunately, "many 
> contemporary MUAs do not have this capability".

Well, actually, most of the bounces I see have the return address and a 
copy of at least part of the failed messsage, so there's not much less 
context than there would be if the MUA were able to fish up a copy of the 
original message.  In any event, as far as I can tell, in the 13 years 
this advice has been on offer, nobody's taken it.  Perhaps it's time to 
give up.

> Some people are still doing pop-before-smtp "authentication".  I advise 
> people to use SMTP-AUTH which is covered by the second paragraph of Section 
> 3.3.  One of the changes to the document is the normative reference to RFC 
> 4954.

Agreed.  My suggestion is to say less about pop-before-SMTP and just 
mention that there are lots of ways to authenticate directly or 
indirectly.  In practice, I find that its problems are less that there's a 
window for bad guys (never exploited that I'm aware of) and more that 
there's no explicit support for it in most MUAs so users are baffled when 
it doesn't work.  ("You have to check your mail." "I did check my mail." 
"You checked it too long ago." "???")

> As I read it, the text mentions the reply code and the enhanced status code 
> to use in such cases.  "Submission rights" might, for example, be viewed as 
> which addresses are allowed in the "MAIL FROM".  I am not sure whether the 
> text is a remnant from Section 3.4 of RFC 2476.

It's unchanged from 2476.  Again, it doesn't seem to have caused much 
damage even though I suspect I am not the only person who doesn't know 
what it means.  Your suggestion seems reasonable, although of course there 
are plenty of other possibilities.

> My litmus test would be: "is this a problem".  I suggest leaving it in.

Certainly harmless.

> I'll apply the same test as above.

It's only a problem if people take it seriously, which doesn't seem to 
have happened in the past 13 years.  Maybe we'll continue to be lucky.

> Section 8.7 goes with Section 8.8 (header rewriting).  The decision for 
> address fields of the header is subject to local policy.  I'm open on this 
> one.

I don't have any personal opinion, other that that it should be consistent 
with whatever the relevant advice for SMTP is.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sat, 28 May 2011 10:49:36 -0700 (PDT)

> return path to the submitting user", it's supposed to reject the mail.

But it also states that having a valid MAIL FROM is one way to meet that
condition.

You appear to be reading this backwards. There are a number of ways to
determine an error reporting path, including but not limited to having
a valid MAIL FROM.

> about.

When a MUA uses a null MAIL FROM it is explicitly saying that it doesn't care
about error reports. In this case it seems rather obvious that the MSA
shouldn't care either

I think this is totally obvious, but if you believe it needs to be clarified
then let's clarify it by saying that this only applies when an MUA says it care
about errors.

  What's "a return path to the submitting user"?  Why should an MSA
> care?

It's a implementation quality thing. The longer you wait to return an error,
the less likely the notification will make it back to the person who needs to
know the message didn't make it.

> in sec 4.2 and explicitly in 5.1.

If a MSA can perform additional validity checks it should.

> nobody's taken the advice, perhaps it's time to stop.

There are several that came out of the X.400 world that do this - it's a GOSIP
requirement, more or less.

I would be inclined to agree with removing this if compliance language
were involved, but AFAICT it isn't. THis is just implementation advice, and
IMO it is sound implementation advice.

> appropriate to the (in)security of the connection?

Sounds like a good idea to me. At this point I'm not even sure that it is sound
implementation advice to recommend IPSec. (I have been forced to use IPSec; it
has not been a happy experience at all and I'm delighted that the trend seems
to be towards TLS or ssh and away from IPSec.)

> always a great idea either.  It would be nice if they agreed.

Still not seeing any real conflict here.

> will happen is a bounce, which may be annoying but doesn't seem "unsafe"

I've seen this practice result in delivery to the wrong recipient. That
seems unsafe to me.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 28 May 2011 14:40:47 -0400

>>   code to the MAIL command. ...

In any event, this language is unchanged since 2476 and it seems to me 
that is that it's so obviously wrong that nobody's tried to do what it 
says, making it harmless.

> know the message didn't make it.

Now I'm doubly confused.  Are we interpreting this as "if the MSA knows 
the message is messed up, reject it?"  That's fine advice, but I can't see 
any relation between that and the existing text.

> There are several that came out of the X.400 world that do this - it's a 
> GOSIP requirement, more or less.
>

Seems a bit odd to reiterate advice that people have been ignoring for 13 
years, but I suppose many of us have teen-aged children.

> Sounds like a good idea to me. At this point I'm not even sure that it 
> is sound implementation advice to recommend IPSec. (I have been forced 
> to use IPSec; it has not been a happy experience at all and I'm 
> delighted that the trend seems to be towards TLS or ssh and away from 
> IPSec.)

OK, will try to invent a sentence or two.

> I've seen this practice result in delivery to the wrong recipient. That

Huh?  I send a message to "foo", an address that doesn't exist because the 
user's address is actually "[email-masked]".  Then what happens?

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sun, 29 May 2011 09:40:52 -0700 (PDT)

> says, making it harmless.

We implemented this advice long before 2476 even existed. While there have been
some peculiar exceptions (like people using an MUA that doesn't show the actual
SMTP error to the user - in this case accepting the message and generating a
DSN later is actually more informative), it has generally proved to be sound.

> the message is messed up, reject it?"

That's the effect of what it says.

> That's fine advice, but I can't see

The relationship seems completely obvious to me.

> years, but I suppose many of us have teen-aged children.

No, what seems odd is wanting to remove sound advice just because it hasn't
been widely implemented.

> user's address is actually "[email-masked]".  Then what happens?

No, what happens is someone sends to foo or foo@bar because that worked in one
context; this gets blindly expanded to [email-masked] or
[email-masked] in another context and gets sent to the wrong user.

Unfortunately lots of places make extensive use of short form names in their
infrastructure and don't think through the consequences, especially for mobile
devices.

Or maybe this is in fact OK with you since you appear to be arguing that
implementation advice should always reflect what implementations actually do
instead or what they should be doing. 

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 29 May 2011 13:25:10 -0400

> That's the effect of what it says.

I can't see how to interpret an instruction about "a return path to the 
submitting user" that way, but as I said, in 13 years it's been harmless, 
so whatever.

> No, what happens is someone sends to foo or foo@bar because that worked in 
> one context; this gets blindly expanded to [email-masked] or

Oh, OK.

> instead or what they should be doing.

Given that our goal is to turn a draft into a full standard, I think there 
is merit to documenting the actual practice rather than advice that's been 
consistently rejected by practitioners for over a decade.  It may not be 
BCP, but it's CP.

Regards,

---

From: Tony Finch <[email-masked]>
Date: Tue, 31 May 2011 15:52:51 +0100

> I certainly wouldn't object to deprecacing this.

We do this. I think it's a good idea, but in practice it's pretty futile
because no-one tries mailing postmaster using an MUA with broken
authentication settings.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.