MAILMAINT at IETF122

Agenda:

• Arnt was unable to present, so we're skipping.
• Might switch order of a couple of items
• Alexey might have something to present as well.
• No other bashing.

With IESG

Wrong Recipient:

• Lisa D: security considerations could be enhanced by privacy
  considerations that we all know but future readers might not (if you
  reply, it gives information that a human exists - worth warning
  implementors)
• John L: Agree with Lisa; possible way to make phishing work (e.g.
  from banks, they know to try different banks)
• Ken: anybody on sender side who wants to implement this?
• John: not yet, will find people.

Keywords:

• Jim volunteered to be Shepherd

UIDBatches

Daniel presenting.

Working with Cyrus IMAP and Apple client. There are working
implementations.

Ken: Running in production at Fastmail. Think it's ready for WGLC.

Alexey: can do WGLC without having implementations. Will try to get my
own implementation soon.

Andy (AD): short answer is "I don't know" about implementations.

Alexey: scanned document, have comments!

Ken: have issue with protocol, or describing text?

Alexey: text - allows too much. Would prefer to make it more how it was.

Expires header field

John L presenting.

Murray: there was an argument that because people have done other
things, we can't standardise it.

John: there's also an argument that providers will use this to silently
delete things, which I don't buy but it was repeated loudly andoften.

Alexey: we have implementations of this, and the fact that X400 has it
doesn't matter. It doesn't delete things, just marks them expired. And
you can set it when it's being created.

Ben: as a client implementor, I wouldn't know what to do with it. Saw
website which promotes this as a green thing; which implies that it gets
deleted. Needs some guidance; what should clients do?

• would be good for 1 time codes too.

Pete: I actually think Ben's questions are all interesting and good, and
they are exactly why we should publish this. The idea that this is out
there, it exists, and clients might not know what to do with it (or
servers) is an important point.
This document saying exactly what the objectors are saying.

• you can't blindly delete this.
• you may want to easily implement a filter for the user, or label
  them, or whatever.
• the only thing this tells you is that the sender is giving you a
  piece of information. Should be up to the end user how to display
  that, or if they want to delete the message, you can give them that
  option too, but it's up to the end user.
• in future if we added an Expires-Because: that would give more
  information.

Ken: agree

Bron: green (saves power) is marketing bullshit and has no technical
bearing.

Jim: expires because, if a sale has ended or whatever - would like to
understand.

Hans-Joerg: we're pondering on expires-because, may be multiple ways a
client would deal with it. Could highlight "expires soon" messages (e.g.
for a sale). On the semantic layer, may be cross relation to SML.
Confirmation codes is a use case we have in SML already. Don't think
it's contradicting. Could use structured schema from SML for the
"because" part.

Barry: I invision gmail will suppress images in a message to reduce
tracking, it has something I can click that says "always show images
from this sender" - would expect "always delete expired messages from
this sender".

• should be proposed standard, because it's proposing a standard.

Ben: agree to should be a standard, am in favour of this. Useful for
systematically sent mail "your parcel is coming, coming today, coming
tomorrow. 1 time codes, etc". Needs to be explicit in specification that
"must not delete without user consent"

Ken: don't think anybody was advocating that server can delete
unsolicited. There's already text in the draft for that.

Tero K: should standardise "expires-because". Not in a hurry, it's
already out there.

Ken: in same draft? Tero: yes, this is hint for the client.

Bron: on expires-because; was against it, now in favour. Should be
standards track.

John will do a draft with expires-because, and see if we likeit.

OAuth

Neil Jenkins presenting.

Barry:

• not a fan of OAuth, think it's flawed for a number of reasons.
• that said, solves the problems you're talking about.
• Support going forward, want to make sure we don't do this INSTEAD of
  looking for other mechanisms.
• Afraid that once we put in OAuth, we'll abandon other options.

Jim:

• there's a lot of subtlty to OAuth, and modes that have been
  deprecated because insecure. Need to coordinate with experts in
  OAuth. Glad to see dkg is here at least virtually.
• does this mean that you need to use a web browser in order to
  authenticate to your email client. Some way to do this natively?

Neil:

• started in OAuth working group; it's been looked at by at least one
  expert there, and talked about in one meeting.
• We've chosen the current best practice and got RID of options.
  Obviously it would go for review with the OAuth mailing list too at
  the end.
• OAuth requires a browser. Not an issue for most uses. If you can't
  do that, you'll have to use a different mechanism.

Ben:

• Share what Barry said, worried this will be the end. There's another
  proposal to use sasl passkeys, it's in the kitten WG.
• If you have other alternatives, please suggest them.

Lisa:

• agree that overall OAuth is very complex, but not worried by the
  approach taken here, because we're explicitly selecting a browser.
• Right now, browser is required - but technically it doesn't have to
  be, and if we build ways to OAuth without a browser, that will fit
  to this.
• Look at live online account at W3C for activity pub. Personal data
  portability archive leads towards that.
• Implementors will find it very familiar if they don't already. Am in
  favour, requires good work.

Ken: to follow up, Neil presented it in OAuth - they are backlogged and
were happy to have it here, but will review it later.

Graeme:

• agree with issues with passwords.
• Issue we have had at Apple with legal agreements, which we don't
  usually have with username/password. Want to avoid going down a path
  with legal agreements at internet scale.

Neil:

• the point with this (open client registration) is that it doesn't
  need a legal agreement.

Bron:

• kitten draft is individual proposed, doesn't seem likely to
  progress.

Vittorio:

• in favour of this, think it's important to find something that can
  be supported by everyone.
• think we already have what's necessary for discovery.

Ben:

• To Graham - worry is that if we standarise it, people will take it
  but STILL require a clientId. Needs to be a MUST not to enforce the
  clientId.
• Make sure provider follows the MUSTs, and not bend on that by
  signing clientId contracts which are not available to all.

Lisa:

• trying to square what I heard from Neil and Graham about legal
  agreements. It would be possible insert a legal agreement page in
  the OAuth flow.
• Bron: clarification -> it's the legal agreement between software
  vendor and service provider.

Neil:

• right now client vendor needs to get a client ID and sign an
  agreement.
• If supports username/password, that ALREADY doesn't need an
  agreement. If service providers want to shut off all access without
  a legal agreement, then IETF can't do this.

Lisa: agree N-to-N doesn't scale!

Neil:

• hope to see some implementations by next IETF.

AutoConfig

Ben Bucksch presenting.

There weren't a ton of people who want to review!

Jim:

• always wince at "best practices". Am aware of places which for
  various reasons have addresses DIFFERENT from usernames.
• Not convinced that it's a good assumption to make.

Ben:

• if you have suggestions, feel free!
• If there's no relationship between email address and login, then
  this won't work.

Daniel:

• important to stress that autoconfig doesn't have to work for 100% of
  people. It's making things work easier for MOST people.
• Similar to OAuth, there will always be people using
  username/password.
• It's helping users.

Hans Joerg:

• disagreeing a BIT with Daniel. See if we can make it useful for
  users.
• another usecase - hosters with decentralised services without a
  central proxy. Will use usernames for logging into IMAP.
• Quick idea, define something like a fallback which encodes the
  server used for configuration (enter some additional "selector" like
  a virtual email address)

Pete:

• experience of autoconfig isn't that it has to match exactly login -
  server can prompt for username and password. So long as it's able to
  ask for that information in the second step, it doesn't matter. So
  long as user can enter a different credential later.
• Certainly microsoft, multiple different logins.

Ben:

• with autoconfig, go to a URL at the ISP with the username in it, the
  ISP can return different parts.
• Regarding asking the user, find that unfair. You already know which
  user they are. Server knows email address, it should populate the
  username field.
• Can always fall back to manual setup.

Pete:

• insisting that username part of credential is identical to username
  is pushing it too far.

Ben:

• documenting what make-better-email. Would you be happy to replace
  "best practice" with other text?

Bron:

• there's definitely cases where things are more complex.
• Think we should solve the 90% case first, keep it simple - if we see
  a lot of need for something more complex, do that later!

Hans Joerg:

• data migration enthusiast
• switching provider is a common case that you're reconfiguring your
  client! Common case when you're moving provider, address exists in
  both places at the same time. Common case where this messes up.

Ben: let's talk about that one offline.

WEBPUSH

Ken: work fits under our charter. Is there interest in this?

Graham:

• There are battery life considerations about getting pushes that you
  don't want, so being able to filter pushes is good!
• ability to pre-register conditions might be useful.

Hans Joerg:

• Migration enthusiast again!
• Might be useful in a migration setting to know if an account has had
  change.
• From a server side, is this hard or easy?

Ben:

• think this is super useful to have in IMAP.
• Had this concrete problem with Android or iOS, can't keep tcp
  connection open.
• Don't want to route things via cloud service or have password for
  user on a server.
• Have reservations about the proposal - would want to specify a
  filter on what to push.

Bron:

• as a server person, we have the data and could make it work.
• as a JMAP person, want to push people to JMAP! But if there's
  interest, we should do this. Question is, are there enough people
  interested to progress this in the group?

Ken: will checkon the list

Data Portability Archive

Lisa Dusseault presenting.

Welcome those who are excited and say let's go.

Bron: yes, keen on this.

dkg:

• also like this work, would be happy to see it progress. Havne't read
  draft.
• Worry about issues with a "shifting archive", wanting to paginate,
  etc.
• can you talk about how to shape the archive format

Pete:

• also haven't read draft!
• can see how this would be interesting in the IMAP/JMAP case. Want
  eml files, structure on top.
• currently there are tools that do IMAP->IMAP transfer, that may want
  to use this as the intermediate format.
• For CalDAV, there's a lot of stuff there. Talked to Bron some time
  ago, server to server migration - custom tooling but not
  generalisable. Being able to do migration would be a wonderful
  thing, not sure a flat archive does it.
• Maybe splitting work would be useful.

Hans-Joerg:

• in many systems, you can't suppress notification for event, or
  change organiser on calendar events.
• See opportunities - if systems can get this data in the new format
  and need to make importer, they might open up different pathways.

Lisa:

• will need some workshopping.
• Not necessarily do it all now.

Bron:

• Incremental archive should be very easy to doon top of this system.

Alexy:

• we want to ask for adoption!

DKIM FBL routing

John L presenting.

Discussion "does this mean bad guys get feedback"?

John: yes, but also

Spamminess codes

Ben: most spam is already being written by AI.

John: most spam in my mailbox comes from Google/Microsoft. If there were
better ways to tell Google, then they might stop sending it faster.

Ben: then why make it public?

Pete:

• answer to public: many providers might want it, even if we woudln't
  tell EVERYONE. So interop is important.
• John: can think of at least 4 providers I'd send this to.
• Pete: are extended status codes something you NEED a document for?
  "Specifiation required", so yes.
• sounds like an experiment - if written up as an experiment, seems
  find for this group to publish and say "would like to see results".

John: not my draft, but experimental seems fine.

Pete: let's point the author at how to write a good experimental draft,
fine for group to takeon.

Updating SMTP IANA registries

Ask for volunteers to review/validate. Ken raised hand.

AOB?

Nope.

Recap

John will add considerations to wrong recipient and take to list

John will roll in expire-because: and take to list

Alexey will implement UIDBATCHES and it will go to WGLC.

Autoconfig: will take to WGLC for existing format. Will churn on new
format.

Webpush and portability - will take to list for interest.

Feedback - ask comcast to make experimental