MAILMAINT NOTES: IETF123

Ken and Murray chairs

Ken presented Notewell, Note really well, etc.

AGENDA Bash:

• Bron has Object ID
• dkg has unobtrusive signatures
• Hans Joerg happy to donate his 15 min
• John Levine wants to talk about mail in deep space (Pete roped into
  being co-editor on)
• Ben Buksch - has time to donate too

Close to finished:

UIDBATCHES

Working at Fastmail, in iOS, etc. Ken asks - who has read the update in
the last month? Has a few small edits made by Daniel. None technical,
editorial clarifications around batch-size issues.

• Arnt and Bron will read it again.

Ken: are you happy Alexey?

Alexey: One case where it talks about server side implementation, batch
size can change drastically if messages removed from the mailbox. Alexey
will review as well, preference is to delete a sentence. Guidance is to
remove a sentence.

ACTION: Ken to do 1 week working group last call for UIDBATCHES, then
shepherd.

Further keywords and attribute names:

ACTION: Ken to do 1 week working group lsat call for keywords and
attributes doc.

Wrong Recipient URL:

Arnt: have implemented expires, and tried to do wrong recipient. Wrong
recipient is harder than expires, it doesn't give me the information I
need about what email I can send after having received it.

If there's a mis-click, the user should be able to do some sort of
communication. If it's not a mis-click, the user shouldn't receive any
information. Had trouble implementing that in Rails. Couldn't tell apps
what they might or might not do.

Think it needs more text about what is permitted afterwards.

John L: don't think we can meaningfully add extra text, because it's
deliberately intended to be non-interactive.

Want to click the button that says "nope", but don't know what we could
add to make it less confusing.

Arnt: will suggest something.

Barry: the idea is that any action taken by the recipient of the "this
is wrong" is for a human to try to fix it.

John: up to the human

Bron: we need a "MUST NOT PUT THE EMAIL ON A LIST OF NEVER EMAIL THIS
ADDRESS AGAIN".

Pete: people can accidentaly click one-click unsubscribes too when they
didn't mean to. This is re-using the mechanism. The receiver could
reasonably say "remove from sending this type of message"

Ken: ask people who think additional text needed, craft and sent for
review.

ACTION: People who want changes to wrong-recipient to craft text and
send to the list for review.

Expires Header

John: one large recipient wanted "Expires Because". Let's document what
we have now, if there's interest in expires-because then we'll do that
later.

ACTION: John to do one more rev of expires.

AUTOCONFIG (legacy)

Murray: will probably need another WGLC, lots of changes.

Discussion point - should it be "informational" or "historical"? It's OK
to go straight to historical.

Ben: thanks for detailed feedback. Plan to address all the points, and
take a look at other feedback.

Two open questions: how to specify XML, don't know how to do that that
I'd feel comfortable to do as a reader and implementer. Haven't seen
other examples that I feel are good. XMPP does little snippets. Find
that readable. If you want something else, need specific instructions.

Murray: example is DMARC reporting has a schema.

Ben: I think a schema can be actively harmful.

Murray: confused about why you think that.

Ben: high risk that people take the schema and reject all documents that
don't follow it.

Murray: can take it to the list.

Ben: in first implementation in Thunderbird was very strict validating
things, was unable to do that because validation was too strict. Client
SHOULD NOT validate the document, just read out what it can get.

Ben: don't believe PACC will replace autoconfig, even though many people
see it this way - there's many cases that autoconfig covers and PACC
deliberately does not. E.G. PACC requires ISP to actively change
configuration in order for it to work. Autoconfig as a design goal
covers all existing configurations without and cooperation from the ISP.

ACTION: More discussion on list for AUTOCONFIG.

OAUTH PROFILE

Neil: main profile spec is in good shape, waiting for implementation
experience and is tied to PACC which is less finished.

Meantime found a recent RFC which will help us decouple more.

For IMAP and POP would propose that you use the well-known path (need
HTTP at imap.example.com to make it work)

Jim: ignoring the protocol bits, has anybody done a user test of this?
Am a bit concerned abou the user experience when using a dedicated email
client, then is has to flip over to a dedicated web browser.

Neil: this is how almost every email client already works for Google,
Yahoo, etc because that's all they allow.

Daniel: think this is a good idea but think there's still value in
having autoconfig for SMTP/IMAP/etc. Would suspect that autoconfig
providing the issuer hostname will be way easier. No harm in client
TRYING to find details here.

Neil: OK.

Ben: Concur with Daniel. Information for OAUTH is one of the things we
need. Don't think it's good to require an HTTP server on the smae
hostname as the application server. Should leave it in the spec. Agree
with Jim that it's a big problem to pop into a browser. Not sure we can
do much about it though given how OAUTH is. Would rather get away from
it for big providers, but don't think we can solve that in this session.

Neil: on Mac and iOS at least there's a system controlled webview which
makes the flow better.

Arnt: speaking as a poor downtrodden user. It's a pain but we're not
adding to it. If it was simple to solve, the other guys would have
solved it already.

Neil: think it's worth adding this as an option for HTTPS protocols, but
for non-HTTP protocols we don't want to specify a well known path
construction. Do we want to put anything inside the SASL responses
in-protocol, or leave it to autoconfig? Advantage of this is it would
work without autoconfig.

Daniel: if you want to do it with IMAP/SMTP and it gives you different
OAUTH things, that's bad! Don't know if it should go in this document or
not.

Ben: putting details in IMAP doesn't solve the "find the IMAP server in
the first place". Once I've found it, I've already used some kind of
autoconfig.

Neil: yeah, this would be for just

SCOPES - semantic vs protocol

Makes it easier to do protocol upgrades; security is about what you
access and what you can do it, not HOW you get there.

e.g. mail scope gives imap, pop, jmap (JMAP registry would have a list
of scopes that give access)

Bron: expect we'll go to more fine-grained scopes at some point. This
might be a thing with partial scopes too.

Ben: as long as mail is defined to add everything that POP/SMTP allows.
Don't see a problem.

• E.G. Google has a real issue with permanent delete (need it for
  IMAP) - full mail permission does not have that.

Neil: this specification would have to define what it means, this
clearly is "gives you full access to mail". People will want restricted
scopes.

Ben: Needs to be a very explicit MUST.

Ben: really really dislike the URL format - one of the reasons being
that the last one is a typo on the slide! Like short and sweet.

Neil: Recommendation from OAuth is URI. People would normally copy and
paste from specs.

Bron: just because it's "full" doesn't mean you're allowed to do things.
Server can have restrictions.

Ben: need to know what the server will reject. Need to disable things in
the client.

Neil: it's already available via IMAP and JMAP.

Ben: this needs to allow the same access you would get via a password
login.

ACTION: Neil will update OAUTH document based on experience. Hope to
WGLC by November IETF.

PACC

Ken: Ben, do you have bandwidth, would you like a co-author?

Ben: very loaded this month. Didn't prepare slides, no change since last
IETF.

Haven't been comments on it. Everything that's had feedback is in there.

If any other changes, need the from the WG.

Ken: if interested, read current draft, send feedback to list.

ACTION: people to give feedback on PACC to the list.

EAI address syntax

Arnt: interoperable addresses

First document -> if you provision this, you'll be fine.

Second document -> allows much more complex things, but good for
validating "this address won't render misleadingly."

UAX31 takes a position on using accents.

Length limits: want us to pick a number as a group. e.g. 64 octets?

Some scripts are not used to accents. If you put a dot below a single
letter, people might just assume a dot on the screen. Other scripts,
they expect an accent.

John Klensin: very much in favour of having some guidance here. One
problem is that the terminology confuses the issues of unicode. Many of
these issues are very general parts of the interface between user
experience and internationalization.

When we talk about accents we're confusing with various other markings
around or inside characters. Confusability of local parts is ultimately
a problem for the mail system, more than globally.

Need to be careful about the terminology and what we do here.

Arnt: I know "accent" is incorrect, but the real name is too long!

John: Hebrew is a good example with complexity with marks.

Pete: local parts, what I want is a representation of me (e.g. my name)
- diacriticals will depend what I can type on my keyboard. Much easier
to type with the diacritical on many keyboards.

For local parts - it's going to be up to the provisioner to decide
what's good. Shouldn't try to limit characters in a global way!

Current text ran into reserverations because it allows diacritical marks
with scripts where no marks are used. Can be used to confuse a user.

Arnt: for what I wrote it's OK. If I run into implementer reservations.
Eg should not be allowed to use a unicode direction change in a local
part? Has been raised.

John: difficulty is one can say "to a mail operator/name allower" that
these kind of things are bad news. So long as we start saying not to do
things, then we have problems. If accented is considered equivalent;
that's similar to considering upper and lower case as the same. Going
far in that direction is problematic.

Domain names: email providers are not connected to the domain name under
which they might be registered two or three levels down. We don't want
to get into the swamp of what rules ICANN makes for subdomains.

Arnt: quick comments. Thanks for suggesting text John.

ACTION: much more discussion for address syntax on the lists.

Push notification payload:

IMAP and web are different, don't need to use same syntax.

Murray: who is asking for it? Who would implement?

Simon: we have proprietary implementation. Can use in IMAP clients. Are
there IMAP implementations?

Ken: anyone with interest? Would you do client or server.

Alexey: unsure but maybe?

Murray: can discuss on list to guage interest.

Ben: very strong interest in webpush for imap in general as a topic.
Don't think the specification matches what we would want.

Simon most of your comments were addressed. If you can review, that
would be good.

IMAP Extension Suggestions

This isn't a new specification.

Arnt: can you talk about relationship between this and IMAP4rev2? Is the
diference big enough? What motivates the difference? Too many equal
things is bad.

Rik: imap4rev2 doesn't include all these things. I read IMAP4rev2 as
"these are things you really should do". This is "you will already be
compliant, this will give your users a better experience".

Barry: IMAP4rev2's goal wasn't to say "you need to implement these to
have a decent IMAP" - it was more "this is a good set of extensions for
the modern day". Would prefer you to build off imap4rev2.

Rik: would have to look at notes. The things required in REV2 that are
required are not the things that have the most benefits for your users.
64bit size for example.

Barry: would prefer to build off REV2.

Bron: this is not a normative thing, it's is useful for clients to know
"lots of servers do this, so even it's not the most valuable, it will be
mostly useful".

Barry: I'll buy that.

Alexey: this isn't the same direction. E.g. QRESYNC.

Ken: this is more a BCP, what's best to do.

Rik: don't think QRESYNC should be required in even REV3, but might be
most useful?

Barry: maybe should make it an applicability statement. I like those.

Rik: will get feedback on the best document types.

Ben: big picture problem as a client, don't know what's out there - how
many servers implement each spec - is it worth doing? Would really like
to see IMAP4rev3 which mandates things and push servers to implement.

Ken (as chair): if we were to consider rev3, would be too large.

Bron: I want to sabotage this so people move to JMAP!

ACTION: Ken will take IMAP4-extension-recommendation to the list and
call for adoption.

MTA Hooks

Mauro: very comprehensive slides

Barry: start by saying "I think it would be important to standardise a
protocol like this" - we tried this 20 years ago and got no uptake. Why
would this be different?

• Feedback from one server; would not add a HTTP engine.
• Would like feedback from other implementers.

Mauro: rspamd developer would do it. User community who use stalwart are
interested. most modern servers have an HTTP stack now. HTTP is taking
over, hence proposing that rather than an alternative protocol. Inviting
other scanners to implement this.

Ken: have closed the queue!

Pete: this is way too big for mailmaint. Our AD is looking worried!
Suggest talk to him about setting up a BOF. Need to make sure there are
people who want to do it. Think it's a great idea, but not mailmaint
sized.

Mauro: seems small for me.

Ken and Murray both agree - people outside this.

Murray: happy to help write a charter.

Jim: we wished we had a similar capability on the output side of the MTA
- an outbound filter. Does this hook work on the output side too?

Mauro: Arnt mentioned something similar. Adding SMTP extension to keep
track of transaction ID. If MTA wants to do DKIM signing on the output
side for example.

Hans Joerg: as someone struggling with milter, agree. Lots of people
struggling with state of the art. Not an expert in this area, but a lot
of MTA incoming queues use SIEVE rules for spam filtering? Wonder how
that would fit.

Bron: Fastmail is building something similar. Lots of other MTAs use
HTTP. It's easy to add.

Arnt: like in general, think BOF is a good idea. Would like to
understand WHY the previous effort failed.

Mauro: dunno, would have to research.

Arnt: start by asking major spam filter people if they are aware of
OPUS.

Alexey: we have something similar. Would like to BOF it.

Unobtrustive end-to-end-signatures

Barry: see only good in this, no downsides. The only reason to not do
it, only reason not to is to roll into DKIM as a first hop.

Bron: want to roll into DKIM2 as a first hop.

Pete: OK for mailmaint to look at this if LAMPS and OpenPGP both say
"fine with us". As an email mechanism it looks fine.

dkg: am a chair on OpenPGP; am happy.

Murray: talk on DKIM list.

dkg: there are multiple implementations.

Ken: people intersted, yes. Multiple implementations.

OBJECTID PARTIAL

Bron: just wrote it, it's very simple, please comment.