Subject: [imapext] Registering $hasAttachment & $hasNoAttachment

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Sun, 3 Dec 2017 18:58:35 -0500

I'm hoping to send these off to IANA by the end of the week, but I thought I
should share these and get them reviewed first.

(We are hoping to use these in Dovecot, and as far as I know the folks at
Fastmail have been using these for a while.)

Thanks,

Jeff.

---
Subject Registration of IMAP keyword $hasAttachment

IMAP keyword name: $hasAttachment

Purpose (description):
Many mail user agents display a hint to the user that a particular email
contains attachments.  Without any help of the server, the user agent needs
to fetch at least a part of the email to determine whether or not the email
contains an attachment.  This is not only wasteful of system resources, but
it also causes a perceivable delay in displaying the mailbox contents to the
user.

The $hasAttachment keyword can be used by the delivery agent to mark a
message as containing an attachment.  The mail user agent can then
efficiently check for the presence of this keyword and convey the
information to the user in whatever way is appropriate.

Private or Shared on a server: BOTH

Is it an advisory keyword or may it cause an automatic action: ADVISORY

When/by whom the keyword is set/cleared:
This keyword can be set by either a delivery agent (through an internal
mechanism) or an email client (using the normal IMAP protocol).  The client
must be able to set or clear $hasAttachment at any time.  The keyword should
be set when the delivery agent or a client has determined that the email
contains an attachment.  If the email does not contain any attachments,
$hasAttachment should be cleared and $hasNoAttachment should be set instead
(see note).

Related keywords: $hasNoAttachment

Related IMAP capabilities: None

Security considerations: None

Published specification (recommended):

Person & email address to contact for further information:
Josef 'Jeff' Sipek <[email-masked]>

Intended usage: COMMON

Owner/Change controller: IESG

Note:
$hasAttachment and $hasNoAttachment are mutually exclusive.  If more than
one of them is set for a message, the email client MUST treat this as if
neither of them is set and SHOULD remove both of them from the IMAP server.

The exact meaning of "has an attachment" is left up to the implementors.
The consequences of implementations disagreeing on what constitutes an
attachment are minor, given that $hasAttachment is intended as only a hint
to the user in the UI.
---
Subject Registration of IMAP keyword $hasNoAttachment

IMAP keyword name: $hasNoAttachment

Purpose (description):
Many mail user agents display a hint to the user that a particular email
contains attachments.  Without any help of the server, the user agent needs
to fetch at least a part of the email to determine whether or not the email
contains an attachment.  This is not only wasteful of system resources, but
it also causes a perceivable delay in displaying the mailbox contents to the
user.

The $hasNoAttachment keyword can be used by the delivery agent to mark a
message as *not* containing an attachment.  The mail user agent can then
efficiently check for the presence of this keyword and convey the
information to the user in whatever way is appropriate.

Private or Shared on a server: BOTH

Is it an advisory keyword or may it cause an automatic action: ADVISORY

When/by whom the keyword is set/cleared:
This keyword can be set by either a delivery agent (through an internal
mechanism) or an email client (using the normal IMAP protocol).  The client
must be able to set or clear $hasNoAttachment at any time.  The keyword
should be set when the delivery agent or a client has determined that the
email does not contain any attachments.  If the email contains an
attachment, $hasNoAttachment should be cleared and $hasAttachment should be
set instead (see note).

Related keywords: $hasAttachment

Related IMAP capabilities: None

Security considerations: None

Published specification (recommended):

Person & email address to contact for further information:
Josef 'Jeff' Sipek <[email-masked]>

Intended usage: COMMON

Owner/Change controller: IESG

Note:
$hasAttachment and $hasNoAttachment are mutually exclusive.  If more than
one of them is set for a message, the email client MUST treat this as if
neither of them is set and SHOULD remove both of them from the IMAP server.

The exact meaning of "has an attachment" is left up to the implementors.
The consequences of implementations disagreeing on what constitutes an
attachment are minor, given that $hasNoAttachment is intended as only a hint
to the user in the UI.
---

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 04 Dec 2017 11:21:47 +1100

> IMAP keyword name: $hasAttachment

We're using $HasAttachment (capital H) at FastMail. Please can we
standardise on this capitalisation? This is consistent with the other
IMAP keyword registrations too.
> Note:
> $hasAttachment and $hasNoAttachment are mutually exclusive.  If
> more than> one of them is set for a message, the email client MUST treat
> this as if> neither of them is set and SHOULD remove both of them from the IMAP
> server.

Surely it SHOULD remove the one that is incorrect rather than both?

Neil.

---

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Sun, 3 Dec 2017 20:53:46 -0500

> IMAP keyword registrations too.

Fine by me.

> Surely it SHOULD remove the one that is incorrect rather than both?

I basically copied the $Junk/$NotJunk mutual exclusion semantics.  It makes
more sense to do what you suggest - and since it is a SHOULD, the client can
just nuke both keywords (useful if the client doesn't have the whole message
downloaded but finds an inconsistency in keywords).

Jeff.

-- 
Research, n.:
  Consider Columbus:
    He didn't know where he was going.
    When he got there he didn't know where he was.
    When he got back he didn't know where he had been.
    And he did it all on someone else's money.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Dec 2017 10:11:37 +0000

Hi Neil,

On 4 Dec 2017, at 00:21, Neil Jenkins <[email-masked]> wrote:

> We're using $HasAttachment (capital H) at FastMail. Please can we standardise on this capitalisation? This is consistent with the other IMAP keyword registrations too.

Sure. IMAP keywords are case-insensitive, but I personally prefer capitalization.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Dec 2017 10:25:16 +0000

Hi,

> Surely it SHOULD remove the one that is incorrect rather than both?

I think everything after "and SHOULD" can be deleted. As presence of both means neither is present, both what is written above and what you suggest is a reasonable course of action.

Best Regards,
Alexey

---

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Mon, 4 Dec 2017 08:22:26 -0500

> >> On Mon, 4 Dec 2017, at 10:58 AM, Josef 'Jeff' Sipek wrote:
...
> I think everything after "and SHOULD" can be deleted. As presence of both
> means neither is present, both what is written above and what you suggest
> is a reasonable course of action.

Right.  Dropping the SHOULD would leave it least constrained.  Suggesting
that either they both get dropped, or that only the correct one remains is
an additional (but very weak) "constraint".

So, the options are:

1. remove the SHOULD completely
2. use SHOULD remove both keywords
3. use SHOULD keep only correct keyword

The $Junk & $NotJunk IANA registration texts [1,2] use option #2.

Finally, I received a suggestion off-list to possibly add something like:

	Whenever a client sets $HasAttachment, the server MAY assist by
	automatically clearing $HasNoAttachment. (and vice versa)

All three options are fine by me (either with or without the server MAY
addition).  I think I have a slight preference for #1 just because it merely
resolves the invalid state.  Once resolved (by ignoring both keywords), the
email is a known state and the client can proceed as normal - whatever that
may be.

Jeff.

[1] https://www.iana.org/assignments/imap-keywords/junk/junk-template
[2] https://www.iana.org/assignments/imap-keywords/notjunk/notjunk-template

-- 
The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers.
		- Bill Gates, The Road Ahead, pg. 265