Minutes IETF104: extra
Email mailstore and eXtensions To Revise or Amend
||Minutes IETF104: extra
EXTRA session minutes - IETF104 Prague - Monday Mar-25-2019 13:50
Welcome Barry as new area director for the EXTRA working group.
CHAT OVER IMAP:
* A chat client, but using email underneath
* proposed "submission token" spec can be used for any email flow,
not just COI
* can always fall back to "slow path", this is an upgrade to faster
mail flow where there's an existing relationship/conversation
happening between the parties.
* Dovecot / OpenExchange have been playing with this for a while
internally - looking for input from this group.
Discussion of details:
* different trust levels: temp/perm - does that make sense? Or
just always refresh?
* does the token come with a submission server name? Not right now,
use MX or SRV. Maybe token should include submisison server hostname.
* discussion of using token to say "prioritise this message" but keep
the flow in band: problem, if everything is special, nothing is special,
and every hop needs to honour this. Still not as fast as direct injection.
* should this use HTTP POST rather than SMTP at all? Pros and cons.
* lots of baggage comes with using email as the transport, but maybe that
frame cost is OK so long as latency is low.
* discussion of "using offsite mail filtering" as a common cause of a latency
path that this could bypass.
* standards-track "delivery-by", if not delivered by a certain time, drop it.
Kind of the opposite of what we want here though.
Dicussion of barriers to adoption:
* many sites won't want to allow direct SMTP injection that bypasses their
corporate firewall. Though if you're running a Jabber server, that does
much the same thing!
* Pro of SMTP vs HTTP post, just connect to a different server with different
creds but inject same existing message via same SMTP protocol - less special
case for client.
Discussions of where the work could happen:
* During the IETF fax working group there was a proposed SMTP immediate
* Way back in 821 there was an SMTP command for exactly this mechanism
* It couldn't happen in EXTRA - this would have to be an SMTP working
* This group was originally chartered without SMTP to avoid distraction and
due to pushback about starting that work.
* If we did SMTP, we'd also redo message format (RFC532 and MIME) and
move them to internet standards.
* ACTION: Bron to write an updated charter for EXTRA, continuing with our
existing maintenance work.
* ACTION: Alexey/Barry to write a charter for an SMTP/MIME working group.
* Last time we met there was interest in a quota extension
* Alexey and Dave Cridland already have an old draft
* Call for co-author, Michael is interested in co-editing
* Discussion of making setquota optional.
* Discussion of "storage used" vs RFC822 sizes. Decided to mirror the
language in RFC8438 STATUS=SIZE:
> [...] it MUST be equal to or greater
> than the sum of the values of the RFC822.SIZE FETCH message data
> item [IMAP4rev1] of all messages in the mailbox.
* ACTION: Bron to issue call for adoption
EXTRA session minutes - IETF104 Prague - Tuesday Mar-26-2019 09:00
* BINARY - agreed that it should be leaf nodes only
* SEARCHRES - include
* MUST sent BYE - much discussion
- e.g. TLS issues, can't even get a BYE down the wire.
- conclusion: remove the MUST
* Mailbox naming: Barry will look over the whole section
- landmines for V1/V2 implementations
- Chris has implemented, subtle issues around bare '&'.
- Server needs to track if client has enabled imap4rev2
- take out DIGEST-MD5 and suggest SCRAM-SHA-256.
- But don't make it mandatory.
- Suspect pushback from SEC ADs about not making it mandatory.
* LIST reference argument
- leave it as it is
- explain why it's there and don't use it unless you have a strong use case
- tell clients to use ""
* LSUB - remove
* Drop CHECK
- know at least 4 servers which implement it differently, nobody seems to mind
- document should advise substring as a sensible default if you don't have an
engine that does something else.
- Barry will look at this.
* Auto \Seen
- don't change anything, but advise use of .PEEK
* UID EXPUNGE will be fixed
* RFC822 vs BODY
- properly DEPRECATE. Advise use of other forms, but don't remove in this spec.
- mention it can be sent in auth responses
* NAMESPACE response -> add some text
* Make sure SEARCH TEXT and SEARCH BODY differences are clarified
* Barry to look at Mailbox Naming
* Barry to look at language for SEARCH
* Alexey to look at capability and namespace text
* NEXT STEPS: hope WGLC soon
* IMAP4rev2 -> June 2019