MAILMAINT AT IETF125

Ken presented the Notewell

Close to Completion Section

Ken presenting state of drafts

• keywords - with editor
• UIDBATCHES - with editor, in use at Fastmail and Apple, tens of
  thousands active users
• Expires - with IESG
• Wrong Recipient URL - waiting implementations
• Extensions Suggestions - have co-author, waiting on OBJECTIDBIS
• OAuth Profile - waiting on OAUTH WG
• Mail Autoconfig - waiting on author (Ben not present)

UTF8 email addresses

Arnt presenting:

Not safe to allow all of UTF8.
There's issues with zero width joiners, needed for some languages.

Barry: why does this have to wait for 5321bis? If you have normative to
5321bis, it will get put in cluster and wait.

• Arnt: heard you have wait for 5321bis to have an RFC number.
• Arnt: we can do WGLC, and some time later in the process is gets
  blocked.
• Arnt: we do need to block until I have tested with lots of email
  addresses.

Barry: BIDI - mixed within same label, or separate labels?

• Arnt: worry concerns mixed left/right (except arabic) in email
  address in general (LHS)
• Barry: thinking about needs with ascii and hebrew name/surname.

John: person who said wait on emailcore wasn't me!

John: the thing that most concerns me is that these two documents in
combination with emailcore, going to create 3 standards which contradict
each other. Carefully think whether this should update existing SMTPUTF8
documents, or at least make it clear what the relationships are.

• Arnt: what is the relationship between RFC6532 (base SMTPUTF8) and
  the other docs.
• Pete: that's going to be the headers doc? Arnt: pretty much.
• Arnt: seems to me these documents go into the cluster with 6532. Has
  the same relationship.
• John: those document explicitly expanded what's possible. In
  contrast, this narrows what's permitted without acknowledging this
  updates those.
• Arnt: For the record, the restriction is that it's not legal to send
  xn-- in the lhs part of an address.
• Arnt: what do you suggest the relationship should be?
• John: agree with ban punycode in localpart!
• John: think the document would be more clear if you separated the
  discussion of localpart and domainpart (which is what 5321/5322 bis
  does)
• This IS a restriction, which is classic AS/BCP stuff, but no
  standards track stuff unless you're updating the core documents.

Pete: John is going the same direction I am.

• These sound closer to BCP/AS. You're giving operational guidance.
• In order to have sane interoperability, it behoves you to (if you're
  creating account names) limit things to.
• Arnt: Makes sense to me. Do you think intended publication status
  (BCP) fixes this?
• Pete: right now it's mushy between syntactic requirement and advice.

• Get rid of domain part entirely, just says "don't use punycode".

  • Arnt: wondering if could reword as just restriction on the
    domain, and localpart must have such and such relation with
    domains.

• Pete: this is implementation guidance for people who are setting up
  account, not just doing clients/servers.

  • Arnt: more than that. There are evil addresses on the net.
    People will do things that you as recipient don't want. What's
    the ruleset for "can I display this address" and as a spam
    filter "can I set the evil bit on this address".

• Pete: so this is the end system (after delivery)

  • These are safe, vs probably unsafe.
  • All that sounds like implementation advice to not things that
    are interoperating on the network, but things on the ends.

• Pete: so framing this as operational advice "if you're running an
  email system, this is what you have to do".

• Arnt: do you agree John?

  • John: think we're saying the same thing. Think these documents
    are a good idea. The problem is that as written right now, they
    create confusion.
  • Partially because you're going somewhere that the IETF has
    normally avoided going.
  • Don't think it's a hard problem - can work with Arnt/John/Pete
    to sort this out quickly.

• Pete: right now the document has a normative reference, just change
  it to the draft - once that happens, go on with the document, and
  magic will happen at the RFC editor level.

Victor: there's a lot of DNS libraries out there allowing understores in
A labels and U labels. Don't know if that overlaps with questions about
defining syntax here or not.

• There's disagreement even about what ASCII is allowed!
• Also since we're talking about email headers in 6532, but the
  question came up about message/global being a mistake. Runs counter
  to the design of MIME - we never should have had multiple layers of
  MIME encoding.
• Don't know where this should be tackled, but raising it here. Think
  we should, at some point, revisit the design of internationalised
  email headers.

Arnt: question to you! Could you send an email telling me what you know
about the differences, particularly with _. In the middle of
implementing idna support in a stub resolver.

Jim: question about just addresses?

• Arnt: bad guys want to do things to cause confusion.
• Does this touch Subject as well?
• Jim: lots of ways Subject can be deceptive without even going to
  unicode. Would tend to constraint this to addresses.

John:

• Don't want to update 5322bis. It says "if you've got non-ASCII in
  there, it's some other document's problem"
• If you want to get this done in a finite time, don't touch
  5321/5322bis.
• With regard to xn-- in an all ascii name, that's decisions we may
  have documented in the original SMTPUTF8 documents.
• Arnt: do we have an RFC references for U labels?

Victor:

• One thing about forbidding xn-- in domain parts, I think that's a
  terrible mistake for practical realities. Some mail clients
  automatically turn things into xn form before sending. Sometimes you
  have no choice; and they might get through.
• I think forbidding it is a strong deviation from real world
  practice.
• In certificiates: if your local part is ASCII, the domain is
  required to be punycoded, so you'll certainly see them in
  certificates, which will create problems for clients on the wire.

Arnt:

• I agree with John and Pete. There are lots of ways to be deceptive,
  using strong language to tighten one part of that is not worthwhile.
• Victor, will answer on the mailing list.

Ken:

• consensus not proposed standard, more BCP/Informative.
• Arnt/Pete/John will work on wording, we can see that once given.

PDPArchive

Alexey presenting

Lisa made a good effort to update document (still as personal name).
Main things are editorial and examples.

Think lisa prefers requiring tombstones with UUIDs, since we already do
that elsewhere (e.g. qresync)

Bron: would like to coordinate history work over in JMAP land with
tombstone handling here.

PACC

Matt presenting

Made one change since Montreal (removed MX option) - there were two
ways. Security requirements for both MX and regular way were the same,
so no convenience issues.

Documents close to done, waiting on implementations

Mauro: started on implementing PACC. While integrating with other
identity providers, not all expose the OAuth well-known path, instead
the use the openid one. E.g. keycloak. -- I know it's not an IETF
standard. Something to consider would be to offer openid as a discovery
option, because the mail server can not control what the identity
provider offers.

• Ken: we can reference something outside the IETF so long as it's
  stable.
• Mauro: openid is very similar, so not much work for implementors.
• Ken: are you willing to craft text?
• Mauro: sure!

OBJECTID BIS

Mauro presenting

Still needs some editorial changes that Bron will make, but here's
what's new.

Ken: I like the implicit enable like with QRESYNC.

Arnt: regarding THREADID, if THREADID changes, there should be a MUST
that the server pushes it to the client. Clients can cache things
forever. If a server assigns new different THREADIDs, that's its
decision. It should have the burden of pushing it.

Mauro: if client notices that objectid changes, it can.

Bron: server should include the

Matt: need to address interaction with JMAPACCESS, right now it says you
have to support OBJECTID.

There's also room for clarifications about the interactions with
JMAPACCESS. The JMAPACCESS says IDs need to be the same between JMAP and
IMAP, but weaker language about "flags between IMAP and JMAP". If a
server supporting both JMAPACCESS and OBJECTID was required to have the
same flags, you'd know from the client if the server was following the
gmail model, or the IMAP regular world. It's nice as a client to know
that.

• Mauro: I agree, JMAPACCESS should be updated.

Bron: suggest that we make this document obsolete both.

Arnt: JMAPACCESS doesn't force it, because different servers do
different things. Some servers have things like hardlinked messages, per
mailbox flags - didn't want to nail that down.

• If someone wants to update it, deal with the problem, I'm their best
  friend!

Ken: will take "should we roll updated JMAPACCESS into OBJECTID+" to the
list

Pete: see the chat

Alexey: enabled responses should be consistent, can send some wording.
Whether it should include all the others.

Unobtrusive signatures

Kai presenting

Bron suggested making it dkim-simple. Thunderbird code has been updated,
but draft not.
Thunderbird test channel has code included. Thunderbird will
automatically verify and render status of message - doesnt yet implement
header check of protected headers.

When producing signed messages, by default, Thunderbird uses multipart
signed by default - for outgoing you need to enable a preference. Still
discussing when and how to change default.

NEW WORK

Victor would like to do something about message/global and MIME.

Ken: there's people interested.

Arnt: would be happy to work with you Victor, not take it on my own.

Martin: Plan to update RFC6068 (mailto: URI scheme). Was waiting because
WG was busy with all kinds of other drafts. Might start with a first
draft. Will have unicode examples. There's some wordage which says "use
utf8 for internationalised addresses" in a forward looking hopeful way
rather than a MUST or SHOULD. That should change.

Also plan to do some testing.

Ken: does URL stuff have its own place? I'll check whether it's in our
charter. If not, may have to go do DISPATCH.

Barry: If we think tweaking our charter works, may have to do that.

Ken: worried about URL police

Barry: URI, we call them URIs.

Pete: it's legit within our charter by my reading.

Andy (AD): haven't checked what the charter says.

Barry: talk with Mark Nottingham and see if that area cares.

Ken: if it was IMAP URIs definitely here, but mailto: less clear.