28 Nov 2011 18:57
22 Nov 2011 07:03
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
16 Nov 2011 10:35
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)
7 Nov 2011 12:49
(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)
6 Sep 2011 16:39
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)
2 Sep 2011 20:37
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)
24 Aug 2011 02:10
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.(Continue reading)>--- > >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.
24 Aug 2011 01:43
Re: Last Call: <draft-ietf-yam-rfc4409bis-02.txt> (Message Submission for Mail) to Full Standard
Hi Frank, At 16:20 23-08-2011, Frank Ellermann wrote: >While at it please convince IANA that they can now s/2476/4409bis/ below >the table in the footnote: > >| * Submit [RFC2476] only. Not for use with SMTP on port 25. There was a note about that in the Document Shepherd write-up. Regards, S. Moonesamy
23 Aug 2011 22:04
Re: Russ Housley's Discuss on draft-ietf-yam-rfc4409bis-02: (with DISCUSS)
Hi Russ,
At 10:45 22-08-2011, Russ Housley wrote:
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>
> The specification says:
>
> If an incoming message includes a DKIM [DKIM], PGP [RFC4880],
> S/MIME [RFC5751], or other signature, sites SHOULD consider what
> effect message modifications will have on the validity of the
> signature, and MAY use the presence or absence of a signature as
> a criterion when deciding what, if any, modifications to make.
>
> This text is a warning that there are dragons here, but it does not
> tell the reader anything about the real consequences. I believe
> that the text ought to be saying that portions of the incoming
> message that are covered by the signature SHOULD NOT be altered.
> The consequences of such alteration should probably be included in
> the security considerations.
The YAM WG was asked for feedback about this issue. Dave Crocker
suggested the following text as a replacement for the text you quoted above:
"Message modification can affect the validity of an existing message
signature, such as by DKIM [DKIM], PGP [RFC4880], and can render the
signature invalid. This, in turn, can affect message handling by later
receivers, such as filtering engines that consider the presence or absence
of a signature."
(Continue reading)
23 Aug 2011 18:48
Re: Stephen Farrell's No Objection on draft-ietf-yam-rfc4409bis-02: (with COMMENT)
Hi Stephen, Thanks for the review. At 04:04 19-08-2011, Stephen Farrell wrote: >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >Given that start-tls is (as stated) the most common >way to secure the submission channel, perhaps the >mention of IPsec in 3.3 would be better replaced >with a reference to start-tls? I posted a message to the YAM WG about this. There wasn't any response. I am going to default to a "no change" as this was not raised as an issue during the WGLC or the Last Call. Please do not read it as meaning that your comment does not have merit. As the intended status of the draft is Full Standard and the text was already in RFC 4409, the barrier for making a change is higher. >typo in IANA cnosiderations? "The table in Table 1..." >s/table/text/? I am waiting for feedback from the editors about fixes to the IANA Considerations section. Regards,(Continue reading)
23 Aug 2011 18:38
Re: Sean Turner's Discuss on draft-ietf-yam-rfc4409bis-02: (with DISCUSS and COMMENT)
Hi Sean, At 07:11 23-08-2011, Sean Turner wrote: >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >WRT to anchor36: Do we expect the RFC editor to ask the IESG before >or after the telechat? I think you could delete it prior to publication. It can be deleted prior to publication. >Appendix B: You could strike 5322 from the list because it's an >informative reference. Yes. Regards, S. Moonesamy
>---
>
>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.
RSS Feed