1 / 9

Authentication-Results drafts

Authentication-Results drafts. Murray S. Kucherawy <msk@sendmail.com>. Internet Drafts. Active drafts draft-kucherawy-sender-auth-header-09 Defines the Authentication-Results: header field draft-kucherawy-sender-auth-esmtp-00 Defines the AUTHRES SMTP extension Upcoming drafts

neola
Télécharger la présentation

Authentication-Results drafts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication-Results drafts Murray S. Kucherawy <msk@sendmail.com>

  2. Internet Drafts • Active drafts • draft-kucherawy-sender-auth-header-09 • Defines the Authentication-Results: header field • draft-kucherawy-sender-auth-esmtp-00 • Defines the AUTHRES SMTP extension • Upcoming drafts • draft-kucherawy-sender-auth-imap • Defines an IMAP annotation for storing authentication results about a message

  3. sender-auth-header-09 • Defines Authentication-Results: header • Used to relay results of authentication checks (SPF, DKIM, etc.) between the border MTA and the delivery MTA • Specifies rules for removing externally-added instances of the header to mitigate forgeries • All the usual discussion (IANA, Security)

  4. sender-auth-header-09 • New in the -09 version (11/8/2007): • Added “iprev” authentication method • Reverse-forward IP address/name validation • References the SPF algorithm as an example, but is deliberately not normative • Discussion of rejecting “hardfail” at the border MTA rather than allowing it inbound added to Security Considerations • Add “dkim-ssp” as a known “method”, different from “dkim” (base)

  5. sender-auth-header-09 • New in the -09 version • Pay homage to the existing “Received-SPF” header field • Not obsoleting or updating it • Better guidance about unknown “ptype” • Mention that the header can be signed for added security • Consensus is against actual normative text encouraging signing • Many editorial comments, ABNF fixes

  6. sender-auth-header-09 • ietf-822, mail-vet-discuss lists pinged last month for feedback in preparation for handoff • Next version will go to the AD for sponsorship • Probably late next week • A shepherd has been chosen

  7. sender-auth-esmtp-00 • Defines new AUTHRES SMTP extension • Used to relay results of authentication checks (SPF, DKIM, etc.) between the border MTA and the delivery MTA • Servers only offer it to MTAs they explicitly trust (i.e. border MTAs) • Removes a vector for forged authentication data

  8. sender-auth-esmtp-00 • Delivery MTA can convert the results to some other useable form • The header defined in the header draft • Can then be used by things like SpamAssassin • The IMAP annotation defined in the IMAP draft • Can then be used by IMAP clients • Need to open it to more audiences for more review

  9. sender-auth-imap • Co-authoring with Philip Guenther • Will use draft-ietf-imapext-annotate (IMAP annotations) to store authentication results about a message • Could extract this information from the header inbound • Easier to get it from the SMTP extension upon relay toward delivery • IMAP clients can retrieve this data and adjust message/summary rendering accordingly

More Related