What is FMTP?

FMTP or Fucking Mail Transport Protocol is a mail protocol designed to try to improve several aspects of email. It includes sender authentication, direct and relayed mail, mail templates and provisions specifically for mass mailers.

PHILOSOPHY:

SMTP was designed to be agnostic of the content being sent. It has very little authentication built in, and very few tools for dealing with abuse. FMTP explicitly diverges from this - aiming to provide some level of identity assurance (does the user actually control the sending account?), specialized distinct types of messages, and more tools for server administrators to use against abuse.

It offers marketers templates, and in doing so allows for smaller impacts on recieving servers and more privacy for the recipient.

It offers expiration dates so that old marketing mail, one time codes, and event announcements can be cleaned up automatically, but explicitly puts control of what happens to that message on expiration in the hands of the recipient.

Encryption is available for privacy as a default, but controlled ultimately by the revieving server, as some servers may have transparency rules.

AUTHENTICATION

Delivering mail to a server requires both the sender and the recipient to have a certificate signed by their respective domains. Both certificates will need to be validated before the transaction occurs.

There are generally two models for authentication: Server to Server and User to Server.

If a user is authorized to send mail directly, their client will generate a private key, then request a certificate to be signed by the mail server. The server will then authenticate the user and issue a certificate with all relevant fields.

The client will then look up the certificate of the recipient by consulting a cache or querying the destination server. The client will then encrypt the message using the recieved certificate, and sign the encrypted message.

Upon delivery attempt, the server will verify the certificate of the sender and the signiture on the message. It will then log the successful authentication of the message and procede with delivery.

For server to server authentication, the flow is similar. The only difference is that the server may either use its own key to sign the message, or grant itself a certificate.

BULK DELIVERY:

Every message in a bulk delivery must be verified and handled individually. A server may also rate limit servers with large mail deliveries.

RELAYS: if a sender wishes to use a third party to relay a message, the message is to be encrypted with the end recipient's key, not that of the relay.

PULL-BASED MAIL

Some messages will require the recipient to pull them instead of pushing to the server. This is done by sending a MAIL WAITING message to the server, incuding a list of recipients.

Servers can madate pull based mail from individual servers by sending a PULL_ONLY signal after authentication. (This helps reduce spam impact). If the server administrator wants to run a pull-only server, they can also use a DNS entry.

When a user checks their mail, they will find they have an additional notification indicating they have mail waiting at another server, and will need to take additional action to pull it.

Well behaved servers will not send a new Mail Waiting signal more than once per day unless the list of users with mail waiting has changed.

If a user decides to Reject Without Reciept, the mail server MAY send a rejection signal OR the mail server MAY accept and discard the mail on behalf of the user.

Note: this design was chosen in part to ensure servers with low reputation can work up to a higher reputation, without enabling spam. Servers without reputation, when locked to pull-only, cannot overwhelm users without it being very obvious where the spam comes from.

TRANSPARENCY CRITICAL SERVERS

Administrators can limit the ability of a user to send their own messages and ensure server side decryption by not issuing certificates for the users own private keys. Instead, a certificate will be issued to the user that uses a key stored on the server. Without the private key, users will be required to send mail through the server.

This configuration is ideal for governents and other agencies with reporting requirements, as it cryptographically ensures that all mail travels through and is available to the server.

REPUTATION

Mail server abuse is a massive problem. Worse: abuse by senders with critical mail puts server admins in a bind. So how do we fix this?

1. Authentication for each message. Every message should be from who it says it is.
2. Each message has its own server fields which keep track of arbitrary properties. This is useful because
3. CLIENT BASED SENDER SHAMING allows for recipients to become aware of the senders misbehavior or recent breaches that may make the mail questionable
4. Encouragement of dedicated marketing tools which shouod reduce the pressure caused by marketing mail
5. Immediate feedback on send for servers that are on the recieving admin's nerves
6. Mail-server directed anonomous and non-anonomous mailing lists, which can help reduce mail addresses getting released and make it easy to unsubscribe
7. Allows for pull based mail, which flips the responsibility for storing mail, and allows it to go undelivered unless the user requests it. This can be set per-server, or be used as a reputation gate without cutting off critical messages.
8. Includes flags instructing clients to show banners, strip out pictures, warn when clicking links, add confirmation before viewing emails, and even reduce a mail to plain text. These changes add friction which can reduce the effectiveness of marketing materials. Companies hate that.

TEMPLATES

Mass-mail or mail that is inside a branded message should consider using templates. In general, a template is a text file with labled fields. It may be encrypted or public, and is stored seperately from the mail's main content.

The main content is delivered normally, but with the "TEMPLATE" field set in the unencrypted metadata. For encrypted templates, the TEMPLATE_KEY field will be set as well.

The reciecing server will pick up the template at its disgression.

MAILING LISTS

For one reason or another, mail servers may need to send out bulk mail. Some may be advertising. Some may be newsletters. Some may be notices. If it is not welcomed by the recipient, however, it creates a problem.

Enter the Mailing List.

A mailing list is a container for a grouping of fmail address. It includes an ID, a name, a purpose, and a priority.

• CRITICAL should only be used for data breach notifications and other rare crisises.
• EVENT is appropriate for short term event notifications. This is also the level at which downtime notifications should be delivered. (The end recipient knows and understands the importance of these messages. They will set their system accordingly.) These messages are assumed to have short term relevance
• MARKETING is appropriate for anything marketing, and should be used for all marketing materials.
• NORMAL is pefect for informational mailing lists and for messages between coworkers.
• AUTH is for truly short term messages such as 2FA codes and recipient verification.

A message from a CRITICAL list should be delivered even for unsubscribed users if the server is sufficiently trusted. Misuse of the CRITICAL list priority, however, will cause the server to lose CRITICAL notification prigelages and may cause other penalties, subject to the judgement of the recieving admin.

Servers should support the following message types:

GetLists (shows a list of existing mailing lists from the server) JoinList (Allows users to request to join a list. May return rejections) LeaveList (allows users to leave a list. MUST BE RESPECTED.) GetList (Gets information on one particular list) IsOnList (Responds with whether a user is on a given list. If the server uses its own certificate, the server should respond with a list of all authenticated users from that server.)

A server that sends newsletters or other mass mail should do the following:

• embrace templates. A message containing only a template ID or a Template ID and a Template Key is a valid message, and templates significantly reduce the footprint of a mass mailer. Also admins are extremely justified in taking away your image and link privelages if you do not comply.
• expose the mailing list in the Mailing Lists endpoint. Include the purpose of the list.
• Respect LeaveList requests. A user who wishes to leave the list is communicating that they are NOT INTERESTED.
• JoinList requests must be set to recieve an appropriate response
• Regularly verify your list with recieving servers to prevent drift.
• Include the MAILING_LIST ID in every mail sent to the list. If a mail is sent to multiple lists, and an individual is on multiple lists, set this header more than once.
• Group recipients by server and send all messages for a server in a single batch.
• Respect UserNotInList complaints by immediatly removing impacted users.

DOWNTIME

Sometimes servers are not up all day every day. A server can include its uptime in a DNS entry, and should check for such an entry before attempting to send mail.