Thanks. I am subscribed. Based on the written charter, is re-introducing then ESMTP add-on,
https://datatracker.ietf.org/doc/html/draft-santos-smtpgrey-02 Reasonable? Many years of operation, the ultimate two questions are: 1) Do greylistng servers support responses to drive greylisted clients? and 2) Do rermote clients honor the advanced response for Retry Times? The above is an example only. Another is ATPS re-introduction for a DMARC-based world. <g> All the best, Hector Santos > On May 10, 2024, at 1:53 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > > FYI > > ---------- Forwarded message --------- > From: IESG Secretary <iesg-secret...@ietf.org > <mailto:iesg-secret...@ietf.org>> > Date: Thu, May 9, 2024 at 1:01 PM > Subject: WG Action: Formed Mail Maintenance (mailmaint) > To: IETF Announcement List <ietf-annou...@ietf.org > <mailto:ietf-annou...@ietf.org>> > Cc: <i...@ietf.org <mailto:i...@ietf.org>>, <mailmaint-cha...@ietf.org > <mailto:mailmaint-cha...@ietf.org>>, <mailma...@ietf.org > <mailto:mailma...@ietf.org>> > > > A new IETF WG has been formed in the Applications and Real-Time Area. For > additional information, please contact the Area Directors or the WG Chair. > > Mail Maintenance (mailmaint) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Kenneth Murchison <mu...@fastmail.com <mailto:mu...@fastmail.com>> > > Assigned Area Director: > Murray Kucherawy <superu...@gmail.com <mailto:superu...@gmail.com>> > > Applications and Real-Time Area Directors: > Murray Kucherawy <superu...@gmail.com <mailto:superu...@gmail.com>> > Orie Steele <orie@transmute.industries> > > Mailing list: > Address: mailma...@ietf.org <mailto:mailma...@ietf.org> > To subscribe: https://www.ietf.org/mailman/listinfo/mailmaint > Archive: https://mailarchive.ietf.org/arch/browse/mailmaint/ > > Group page: https://datatracker.ietf.org/group/mailmaint/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-mailmaint/ > > Internet Messaging (“email”) is one of the oldest applications still > supported by the IETF. It consists of numerous layers and extensions that > support the robust construction, transport, retrieval, and interpretation of > messages. > > (For the purposes of this charter, “email” starts in RFC 5321 which covers > transport and RFC 5322 which covers message format, and extends into > specifications based on those documents and their antecedents. It also > includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et > seq].) > > >From time to time, new work in the email space is brought to the IETF for > consideration and development. Where there is enough critical mass to create > a working group to develop and publish the work, this is the preferred case. > More often, however, a proposal is brought that lacks enough critical mass to > independently support chartering of a working group, but would still be > useful to publish as a standard. Such projects must then either seek the > assent of an Area Director willing to sponsor it as a standards track > document, or support via the Independent Stream Editor (ISE) without > standards track status. > > The MAILMAINT (“Mail Maintenance”) working group will consider projects in > the email space that are too small to warrant construction of a dedicated > working group. This will take advantage of a common community to consider > these proposals rather than forming a series of disparate but related > communities. > > Work proposed for MAILMAINT may arrive via direct proposals, or it may be > referred via one or more DISPATCH-style working groups. Recorded Calls for > Adoption are required for all work proposals. > > Proponents of work that is not taken up within the IETF may, of course, > decide to bring their proposal to the Independent Stream. The working group > should discuss such proposals with the ISE and share the results of the > working group’s consideration. > > Further, MAILMAINT will observe the following constraints when considering > the adoption of new work directly: > > * Prior to accepting any Standards Track document for development, there must > be a commitment to implement the resulting proposed standard from at least > two independent parties, as recorded on a related IETF mailing list. > > * When deciding to send any Standards Track work to the IESG, there must > first be produced a report documenting at least two (preferably more) > independent implementations with at least partial interoperation based on the > developed specification. > > * The above constraints do not apply to documents that are not intended for > the Standards Track. > > * Chartering of a dedicated working group with a custom charter is strongly > preferred when engaging any work that updates any base email documents, > including but not limited to those identified above. > > All work will be announced to appropriate non-WG lists such as ietf-822, > ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Group > Last Call begins. > > Standards work being taken up by MAILMAINT should be checked with other > relevant areas (mainly Security) to confirm appropriate oversight or possible > assignment to that area. > > Milestones will be used to track all approved work, including during > chartering and rechartering. > > Milestones: > > Jul 2024 - Call For Adoption of draft-dweekly-wrong-recipient > > _______________________________________________ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
