Systemspace Network List Network Enhancement Idea 5 Quintuplicate 12 July 2021 [Affected by NEIs: 7] SPECIFICATIONS FOR SYSTEMSPACE NETWORK IMAP CLIENT 0. Author's Note As the number of email addresses in SSN-l grows, it will become more and more inconvenient to reply to all of them. To solve this problem, Yori has proposed that a simple IMAP bot be coded in Python which will have an account, check for new messages every 5 minutes, and send them to every address on SSN-l. I volunteered to write the first draft, but I could only get some preparatory work done today. This NEI reports what I did not only to SSN-l but the larger Systemspace community, consisting of (I) a summary of RFC 2060, which defines IMAP, (II) proposed specs for the Systemspace Network IMAP Client (SNIC) beyond the requirements of RFC 2060, and (III) a philosophical position on SNIC. Note that I am an idiot and you should mock me mercilessly for any PEBKACs or layer 8 issues I may have committed, that I may improve. I. RFC 2060 Internet Message Access Protocol (IMAP) is a protocol for reading and processing emails remotely but not for sending them (that's a job for SMTP). The current version of IMAP is IMAP4rev1, and it is defined by RFC 2060. This RFC revised RFC 1730, which defined IMAP4. Both were written by Mark Crispin at the University of Washington in the 1990s, and are generally compatible. With IMAP, clients send commands and servers reply to them with responses. Every command must be tagged with an alphanumeric string like A001. Responses to commands are prefixed with the tags of the commands they respond to, but servers may send responses that do not correspond to any command, in which case they are untagged and prefixed with a "*" where there otherwise would be a tag. Every message has a unique identifier (UID) and a message sequence number. The UID is a 32-bit value that never changes. The message sequence number changes based on the relative location of the message within the mailbox. Both are assigned in ascending order: a message added to a mailbox after another message has a higher UID and message sequence number than the other message. Messages are grouped in mailboxes. Every mailbox has a unique identifier validity value (VV). The VV is a 32-bit value as well. Every message is uniquely identified among all the messages in the server by the 64-bit combination of its UID and its mailbox's VV. Mailboxes can be hierarchized. A client can be in one of 3 states. If an IMAP server is a hotel, the non-authenticated state is the lobby, the authenticated state the corridor, and the selected state the rooms. You can go from lobby to corridor (AUTHENTICATE or LOGIN), from corridor or room to room (SELECT), from room to corridor (CLOSE), and from room or corridor to outside (LOGOUT). You cannot, however, go from corridor to lobby without dis- and reconnecting. You can authenticate with plain LOGIN, which is just a username and a plaintext password. With AUTHENTICATE, however, any form of authentication the parties recognize can be used. The server will send a challenge, the client will reply with an answer, and this process repeats for as many times as is agreed. The parties can also opt to engage a protection mechanism that will encrypt the connection once authentication is complete. Once you are in, you can SELECT a mailbox to work on just that mailbox, or EXAMINE a read-only mailbox. You can also CREATE, DELETE, RENAME, SUBSCRIBE to or UNSUBSCRIBE from (UNSUBSCRIBE), LIST all, or just subscribed (LSUB), meeting your specified criteria, check the number of unread messages and other data about (STATUS), or add messages to (APPEND), mailboxes. Within a mailbox, you can SEARCH its messages, FETCH their text or metadata or alter it (STORE), COPY messages to other mailboxes, or find out their UIDs (UID). You can also EXPUNGE messages (totally delete them). II. Proposed Specifications for SNIC If these specifications are not met, then it will not be desirable to switch from our current system to SNIC. - It must comply fully with RFCs 2060 and 1730. - It must have a way for a listmaster to log in, and watch emails sent to the address - pass through any good-faith emails that make genuine contributions, EXPUNGE malicious/spam emails. Every member of SSN-l should be able to observe the listmaster. - It must have a way to reject certain IPs that are proven malicious from connecting: go straight to disconnecting as soon as they connect. These specifications are nice to have but not essential. - It may have an option where members of SSN-l can choose to have emails delivered individually, or in a "lump sum" every day. - It may have a way to collate and (if desired) publish logs. III. A Philosophical Position I believe we should adhere to the principle that anything we do for the convenience of our work should also be used for the benefit of the community, if possible. With NEI 4 declaring that the standard provisionally defined in NEI 2 will be used not only for NEIs but also for general formatting, I think we are halfway to recognizing this principle already. Hence, SNIC should be made available for members of the community who want to start their own mailing lists. The idea of selling email addresses to raise money has been discussed, but runs into some tax issues that are best discussed after we have made a decision on SNIC. But if we do choose to do that, SNIC could prove a major benefit and incentive that would really destroy the competition.