Administrivia
3 min - Scribe selection / NOTE WELL
2 min - Agenda bashing
Active Drafts
5 min - Updated Use of the Expires Message Header Field - John Levine
5 min - Adding a Wrong Recipient URL for Handling Misdirected Emails - David Weekly
15 min - Mail Autoconfig - Ben Bucksch
Proposed Work
10 min - SMTPUTF8 address syntax & Nice Email Addresses for SMTPUTF8 - Arnt Gulbrandsen
10 min - Registration of further IMAP/JMAP keywords and mailbox names - Neil Jenkins
25 min - OAuth Profile for Open Public Clients - Neil Jenkins
Topics of Interest
15 min - DKIM2 Why DKIM needs replacing, and what a replacement would look like - Bron Gondwana
AOB
If time permits
Milestones
If time permits
John: Richard Clayton from Yahoo says "probably won't implement this as written"
Richard: was said on list "who will implement this?" - nobody said they will.
Ben: does "Expires" mean no-longer relevant. Mustang (new email client)
John: If inbound mail providers won't implement, then we can't take to last-call.
Alexey: we have implemented this for the last 10 years. Both sending and receiving. Added to our webmail.
Ken: if someone else implements, we can take to last call.
John: Richard said "won't implement this either". Will be one or the other - can we combine them? Semantic hint or "should have Unsubscribe and interpret as not me"
Neil J: viewed this as the same thing. Combine with a tag or separate, doesn't matter. Would never have both. Could help client present it differently.
John: will go back and see if we can find people who would implement.
Murray (AD): minor administrative point - set for Feb. Want to push them out?
Neil: would implemnt it. Ben and Alexey too (by hands).
Ben: List vs not-me are semantically different - know if this is a list.
Bron: would be great if you could look for List-Id
Neil: you can't - know, lots of things don't have a List-Id because Google/Yahoo don't require it, and you can't know if the same sender was the same list.
Pete: Propose a parameter to List-Unsubscribe.
Ken: will that break existing implementations?
Richard: Have recently looked at List-Id headers in real email at scale - there's a large number of people who have not read the RFC and have no idea what should be there. They put a unique identifier (one per message)
Ben: worked 25 years on Thunderbird, now creating own client.
Thunderbird has been using autoconfig since 2008.
Have autoconfig + ISPDB + MX - 80-95% total work.
First though of being standards track - make informational instead? One more revision to come out. Do we know how to specify XML formats in RFCs? XSD?
John L: in DMARC RFCs, where there's XML reporting format, there's an XSD but it's clear nobody reads it. Think it would be good to put it in, if you mark it as code then people can extract it mechanically if they want it.
Ken: can ask the RFC editor downstairs.
Last week we came up with a new format:
SRV _serverconfig._tcp_.%DOMAIN%
If unable to set DNS records as a big provider, can use MX;
MX %DOMAIN%
May not work in some really rare cases. Then we look up
SRV _serverconfigmx._tcp.%MXHOSTNAME%
Both return a URL - which gives a JSON with all the info to configure the client.
Q from Arnt: do you have any kind of policy there? E.g. "we support passwords, really want to phase them out"
* Ben: we considered - but clients will just do what they want. Shouldn't be in protocol.
We're not doing StartTLS - everything is required/implicit TLS.
Metadata as well.
To be clear - two drafts. Informational about current behaviour is nearly done. New one the IETF way needs to be written up still.
Arnt: Want to get rid of some of the wilder parts of UTF8.
propose: single draft with sections
John K: liberal syntax adopted by EAI working group was probably a mistake. It's a good idea to tighten things up.
Reason I've been arguing to separate these things - there are reasons to deliberately obscure local parts in email addresses. If name+obscure part of localpart; that's intentional. Should make it no more restrictive then necessary.
Think both worthwhile; but need to think about them differently. Whether one or two documents is RFC user experience question - but if labeled as "updating SMTPUTF8 documents" should not also go into other things.
Ken: if WG takes on work, will keep separate for now and determine if we want to merge them.
Jim (from Jabber): single script rule is harmful. Japanese uses multiple scripts+ASCII.
Arnt: input methods consider these to be one script (one name which is these 4 scripts) - there are also a couple of other similar things.
Alexey: maybe use this as an example and explain what you mean by "single script".
Arnt: Will do.
Neil: we realised we're using a bunch of keywords that aren't registered.
Likely to be informational.
Notify, Mute/follow, Memos.
Ben: are you clearly defining semantics of these?
Neil: spec is meant to have enough detail to be interop
Bron: Daniel has also proposed something. Suggest we should combine them into a wrap-up of "known keywords"
Alexey: want to add support.
John K: in favour of WG developing UTF8 keywords.
Alexey: non-ASCII keywords are not allowed in IMAP and JMAP.
Bron: if you want to do UTF-8 keywords, that's re-defining the registry, don't think there's any interest here but feel free to propose.
Ken: documenting existing practice.
Neil: AD sponsored or Mailmaint?
Ken: Mailmaint, presumably multiple authors.
Passwords are bad.
OAuth seems the only option; right now big providers can force it, but no interoperable way.
Need something that doesn't require pre-existing relationship, otherwise it won't scale. Have come up with a profile of OAuth which solves this. Doesn't define anything new, using existing IETF standards and defines a profile of them.
Step 0: Autoconfig (what Ben presented earlier)
Step 1: standard JSON (RFC8414) OAuth metadata. Static JSON file. Will define a registry of scopes interoperable.
Step 2: Dynamic client registration (RFC7591). Static client JSON file. Server gives htem a client ID. Client can only use local or private. Too easy to phish users if in the web; if running locally then can already do things.
Step 3: Authz Code Grant flow (RFC6749). Reduced options to make it secure and easy to operate. Pixie with hash of code challenge.
Step 4: Swap for access/refresh tokens
There's SASL auth bearer for IMAP/SMTP and standard HTTP bearer for HTTP based protocols.
...
More secure, easier to set up, easier to revoke.
Presented at OAuth group at last IETF - there's no new OAuth bits, so happy for the work to happen here.
Murray: based on a conversation that's bouncing around, would like to see discussion of whether it's too big for OAuth.
Ken: OAuth chair, wants it here - they have too much going on. Scoped to email, not adding more to OAuth.
Murray: is it too big for this charter? Doesn't seem a simple little thing.
Jim Fenton: Want to make sure not confusing OAuth with an authentication protocol. Could use password to give you access to OAuth. Is scope of token specific to accessing email?
Neil: yes, this is standard OAuth - the token is often scoped for just what you need. If you login with the password directly to provider's website, gives access to more. But the point is that client isn't storing the password. Also refresh token allows detection of stolen and duplicated elsewhere.
Jim: comment on working groups; there's UTA - using TLS for application. Maybe need a "using OAuth for applications"? Maybe talk with Aaron and see if similar requests from other places.
John K: this feels like (as Keith said in the chat) we're making very strong assumptions about what an email client is like. This is lightweight if it's a web implementation, it's heavy-weight if it's not.
Neil: vast majority of clients this is straightforward, indeed they already do this. Also email ecosystem is a broad field, not everything needs to server everyone. This serves a real need for a lot of people.
John K: concerned about accelerated array in which we're squeezing ourselves to a small number of providers.
Bron: we're so keen to deal with the edge cases we never solve the common case.
Neil: this is increasing interoperability and the ability for more than a handful of providers.
Pete: if you require calling out to a website. Current OAuth protocol doesn't include "website must support Javascript" - need to comb that out.
Neil: don't think you can comb that out. If who you host your mail.
Ben: the problem right now is that many companies are moving to Office365 because it's the only way they can get OAuth in client. The good thing about this spec is to narrow down the options.
As a mail client, I'm required to have a chrome browser (or can use safari/firefox) - that scope is completely undefined. That's not a protocol. I need to know, do I need cookies.
Ben: I'm forced to authenticate with OAuth - there needs to be a barrier between my web browsing and my email.
Ben: most companies mandate Outlook.
Neil: yes and if they do, there's nothing we can do about that. Neil - "only works in chrome" - then that's a problem with your client.
Arnt: wrote an OAuth client on a constrained device. Knowing what was required for interoperability was required. This specification needs some sort of statement on what the web browser needs to be able to do.
Neil: can have recommendations, hard to say anything normative.
George Michaelson: using mechanistic approach to connect to Microsoft. It's just a protocol exchange over https which creates a cookie state. Get the call to say "you must use edge". My observation is that what happens right now doesn't enforce a particular browser. Am connecting to Microsoft right now; without using a browser.
Daniel: think most people agree OAuth isn't ideal - it's moving things forward. If someone wants to come up with something better then please do.
Neil: waiting 10 years for something better