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 <[email protected]> wrote: > > FYI > > ---------- Forwarded message --------- > From: IESG Secretary <[email protected] > <mailto:[email protected]>> > Date: Thu, May 9, 2024 at 1:01 PM > Subject: WG Action: Formed Mail Maintenance (mailmaint) > To: IETF Announcement List <[email protected] > <mailto:[email protected]>> > Cc: <[email protected] <mailto:[email protected]>>, <[email protected] > <mailto:[email protected]>>, <[email protected] > <mailto:[email protected]>> > > > 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 <[email protected] <mailto:[email protected]>> > > Assigned Area Director: > Murray Kucherawy <[email protected] <mailto:[email protected]>> > > Applications and Real-Time Area Directors: > Murray Kucherawy <[email protected] <mailto:[email protected]>> > Orie Steele <[email protected]> > > Mailing list: > Address: [email protected] <mailto:[email protected]> > 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 -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
