RFC Errata System | 3 Jun 20:36 2014

[Errata Verified] RFC6409 (3995)

The following errata report has been verified for RFC6409,
"Message Submission for Mail". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6409&eid=3995

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Tony Finch <dot@...>
Date Reported: 2014-05-22
Verified by: Barry Leiba (IESG)

Section: 8.7

Original Text
-------------
   NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in
   addresses and the session-opening announcement.  As with other SMTP
   requirements, RFC 5321 effectively prohibits an MSA from forwarding
   such messages into the public Internet.  Nonetheless, unconditionally
   resolving aliases could be harmful.  For example, if www.example.net
   and ftp.example.net are both aliases for mail.example.net, rewriting
   them could lose useful information.

Corrected Text
--------------
   NOTE: RFC 821 and RFC 1123 prohibited the use of domain name
(Continue reading)

Tony Finch | 3 Jun 18:40 2014
Picon

Re: [Technical Errata Reported] RFC6409 (3995)

John C Klensin <john-ietf@...> wrote:
>
> Actually, something else just occurred to me.  I don't think it
> changes the "verified" answer and I can't remember why Randy and
> I left the prohibition there when it was removed from SMTP.

The text in section 8.7 that I reported the problem with is new in RFC
6409 - it was not present in RFC 4409. It isn't something you "left". It
looks like it was added to provide more rationale for the MAY provision in
that section.

The MAY is there (I think) because Sendmail does the rewrite that the MAY
permits, and most other MTAs/MSAs do not. In RFC 4409 the rationale simply
discourages MSAs from rewriting, which is consistent with the change in
DRUMS several years earlier to remove CNAME canonicalization, and which
agrees with the argument you laid out in the message I am replying to.

The error is that RFC 6409's expanded rationale is completely backwards.
It makes it sound like the MAY is giving MSAs permission not to rewrite
when it would otherwise be required by RFC 5321. However there is no such
requirement in RFC 5321, and the MAY is actually giving MSAs permission to
rewrite even though it is not necessary and can be harmful.

So the point of my suggested replacement text is to explain the historical
background which has led to some MSAs doing a rewrite which we now
consider to be misguided. Yes it is suboptimal - it could indeed be
improved by expanding pronouns as Randall suggested, and I should not have
left out the perfectly correct sentences that came from RFC 4409.

Tony.
(Continue reading)

Barry Leiba | 27 May 19:59 2014
Picon

Re: [Technical Errata Reported] RFC6409 (3995)

*** ACTION FOR RFC EDITOR ***

>>>  OK... then please agree on an exact wording change to the
>>>  errata report, and I will get the change made.
>>
>>  If Randy has strong preferences to the contrary and wants to
>>  take the lead to sort out wording, I'll defer to him.   But my
>>  preference right now, based on avoidance of pointless work,
>>  would just be to add a sentence to what is in the erratum
>>  already that says "the above wording is not quite correct and
>>  needs to be examined carefully before a revised version is
>>  inserted into a revised document" ... or something to that
>>  effect - exact wording doesn't make any difference.  In other
>>  words, I recommend flagging this rather than trying to develop
>>  supposedly-final text that would just need another pass if/when
>>  the document is revised.
>
> WFM.

OK... then:

RFC Editor: Please return this errata report to "Reported" state so I
can make the changes.  Thanks.

Barry

Randall Gellens | 24 May 21:08 2014

Re: [Technical Errata Reported] RFC6409 (3995)

Consider the work to add the clarifications as a down payment on the 
work of any eventual revision, or insurance that a revision will be 
done without forgetting this discussion now.  Or, if it's worth 
publishing the errata, it's worth noting that it isn't quite right.

At 7:51 PM -0400 5/23/14, John C Klensin wrote:

>  --On Friday, 23 May, 2014 18:01 -0400 Barry Leiba
>  <barryleiba@...> wrote:
>
>>  Is it sufficiently important to add the note that I should ask
>>  the RFC Editor to pull it back, so I can add the note and
>>  re-verify?
>
>  Depends...
>
>  If you expect that Randy and/or myself will revise the doc
>  within the next year or two, this discussion thread suffices and
>  there is no need to do anything else -- not going to forget any
>  time soon.  I imagine we could quibble about the text and spin
>  up a version with the change in less time than we've spent on it
>  in the last week, but getting it through Last Call and approved
>  (and preventing that from turning into a debate about the
>  fundamental philosophy of email and its relationship to the DNS
>  and the differences in character among the three Pu-ers I got to
>  compare yesterday) would be your problem, not ours.
>
>  Almost the same answer applies if the expectation is that the
>  spec will never be revised: IMnvHO, we are spending a lot of
>  time hair-splitting about fussy original text for which a
(Continue reading)

IESG Secretary | 28 Nov 18:57 2011
Picon

WG Action: Conclusion of Yet Another Mail (yam)

The Yet Another Mail (yam) working group in the Applications Area has 
concluded. The IESG contact persons are Pete Resnick and Peter Saint-Andre.

The mailing list will remain active.
Pete Resnick | 22 Nov 07:03 2011

Last Call for YAM shutdown

I plan to send the message in approximately 24 hours to shutdown YAM, 
leaving the mailing list open. Speak now or forever hold your peace.

pr

--

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

rfc | 16 Nov 10:35 2011

STD 72, RFC 6409 on Message Submission for Mail


A new Request for Comments is now available in online RFC libraries.

        STD 72        
        RFC 6409

        Title:      Message Submission for Mail 
        Author:     R. Gellens, J. Klensin
        Status:     Standards Track
        Stream:     IETF
        Date:       November 2011
        Mailbox:    rg+ietf@..., 
                    john-ietf@...
        Pages:      20
        Characters: 40153
        Obsoletes:  RFC4409
        See Also:   STD0072

        I-D Tag:    draft-ietf-yam-rfc4409bis-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6409.txt

This memo splits message submission from message relay, allowing each
service to operate according to its own rules (for security, policy,
etc.), and specifies what actions are to be taken by a submission
server.

Message relay is unaffected, and continues to use SMTP over port 25.

When conforming to this document, message submission uses the
(Continue reading)

Leonidas Lymberopoulos | 7 Nov 12:49 2011
Picon

(CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012)

-----------------------------------------------------------------------------------------------------
  Please accept our apologies if you receive multiple copies of this CfP
-----------------------------------------------------------------------------------------------------

IEEE/IFIP International Workshop on Management of the Future Internet  
(ManFI 2012)
==================================================================================
16 April 2012
Maui, Hawaii, USA
http://www.manfi.org

CALL FOR PAPERS
---------------
The Fourth IEEE/IFIP International Workshop on Management of the Future  
Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012  
in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by  
the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE,  
Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by  
the Technical Committee on Network Operations and Management (CNOM).

It is widely agreed that, despite its many successes, the current Internet  
also has a set of systemic problems, ranging from an upcoming shortage of  
IP addresses to insufficient security. However, the lack of scalable and  
agile manageability is arguably more important, as without management, it  
is impossible to build systems that adapt the services and resources  
offered in a context-dependent manner.

In either case (clean slate vs. evolution vs. revolution) we must consider  
the manageability of the Future Internet from the beginning. Following the  
success of the three previous editions of this workshop, held in  
(Continue reading)

The IESG | 6 Sep 16:39 2011
Picon

Protocol Action: 'Message Submission for Mail' to Full Standard (draft-ietf-yam-rfc4409bis-03.txt)

The IESG has approved the following document:
- 'Message Submission for Mail'
  (draft-ietf-yam-rfc4409bis-03.txt) as a Full Standard

This document is the product of the Yet Another Mail Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-yam-rfc4409bis/

Technical Summary

This document splits message submission from message relay, allowing each
service to operate according to its own rules (for security, policy, etc.)
and specifies what actions are to be taken by a submission server.

Working Group Summary

The YAM WG adopted a two-step approach to move this document to Full Standard.
The first step was a pre-evaluation of the existing specification to identify
changes and non-changes. The second step was to incorporate the changes into
the document and ensure that any implementation that conforms to the Draft
Standard version of the specification remains compliant with this document.
There was no controversy. There is consensus to move the specification to
Full Standard.

Document Quality

The document has a high degree of technical maturity. In the five years since
(Continue reading)

internet | 2 Sep 20:37 2011
Picon

I-D Action: draft-ietf-yam-rfc4409bis-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Yet Another Mail Working Group of the IETF.

	Title           : Message Submission for Mail
	Author(s)       : Randall Gellens
                          John C Klensin
	Filename        : draft-ietf-yam-rfc4409bis-03.txt
	Pages           : 22
	Date            : 2011-09-02

   This memo splits message submission from message relay, allowing each
   service to operate according to its own rules (for security, policy,
   etc.), and specifies what actions are to be taken by a submission
   server.

   Message relay is unaffected, and continues to use SMTP over port 25.

   When conforming to this document, message submission uses the
   protocol specified here, normally over port 587.

   This separation of function offers a number of benefits, including
   the ability to apply specific security or policy requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-yam-rfc4409bis-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
(Continue reading)

S Moonesamy | 24 Aug 02:10 2011

Re: Adrian Farrel's No Objection on draft-ietf-yam-rfc4409bis-02: (with COMMENT)

Hi Adrian,

Thanks for the review.

At 15:16 23-08-2011, Adrian Farrel wrote:
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I have no objection to the publication of this document, but here 
>are some piddle-nits you might look at in the interest of making the 
>draft so highly polished that you can see your ^H^H^H face in it.

Polished drafts rarely make it to Full Standard. :-)

>---
>
>idnits says...
>   -- The draft header indicates that this document obsoletes RFC4409, but the
>      abstract doesn't seem to mention this, which it should.

RFC 4409 obsoletes RFC 2476.  That RFC does not mention that fact in 
the Abstract.  The "should" might have been appropriate if the draft 
was not intended to be published as a Full Standard.

>---
>
>I think you are not supposed to include citations in the Abstract.
>On the other hand, it might be nice to include the reference to
>[SMTP-MTA] in the first paragraph of Section 1.
(Continue reading)


Gmane