Skip to content

Latest commit

 

History

History
205 lines (149 loc) · 7.63 KB

basics-alterations.md

File metadata and controls

205 lines (149 loc) · 7.63 KB
title prev up next
Message alteration
basics-acceptance.md
basics-workflow.md
basics-delivery.md

Message alteration

Sympa's sympa_msg.pl daemon fetches incoming messages on the incoming spool, $SPOOLDIR/msg directory. Then it creates an memory image of the message for later processing. At the end, the processed image is stored into outgoing spool, $SPOOLDIR/bulk directory, and bulk.pl daemon fetches and dumps it to the mail transfer agent (MTA).

Does Sympa alter messages?

The intermediate image described above might be altered. However, if a message is S/MIME signed, it should not be altered, because any changes in any part of the message body would break integrity of the S/MIME signature.

Sympa might perform the following changes to the messages to be distributed. Some of these alterations can be configured.

Decrypting

  • If a message is encrypted and S/MIME certificate of originator is valid, decryption is tried. Later this message may be encrypted again (see below).

Altering message header

  • X-Sympa-Topic header field is added as necessity.

    See "Message topics".

  • If anonymization mode is enabled, several header fields are removed or consealed.

    See anonymous_sender and anonymous_header_fields parameters.

  • The subject of the message might be changed to add a custom subject tag.

    See custom_subject.

  • Additional header fields are removed according to customizations.

    See remove_headers and remove_outgoing_headers.

    Note

    • remove_headers does not remove header fields described after this, but remove_outgoing_headers can do. Use the latter one only when you know what you are doing, or messages might not be distributed correctly.

  • Reply-To header field is altered according to configuration.

    See reply_to_header.

  • X-Sequence header field is added. Its value is the sequence number of posts.

  • Some header fields are added/removed to prevent mail loop.

    See "Loop prevention".

  • Sender header field is added/altered. It should have appropriate value to satisfy some sender domain validation systems such as DKIM, Sender ID.

  • Header fields configured by custom_header are added.

  • Some mailing list header fields for RFC 2369 compliance (see rfc2369_header_fields) are added. Also, List-Id (RFC 2919) and Archived-At (RFC 5064) fields are added.

    • Note that, if message personalization is enabled (see "Message personalization") and DKIM signing and/or ARC sealing are enabled (see "DKIM and ARC features for Sympa"), List-Unsubscribe RFC 2369 field will be replaced with the List-Unsubscribe and List-Unsubscribe-Post fields for RFC 8058 One-Click Unsubscribe at the step described in the next section.

      Note

      • RFC 8058 One-Click Unsubscribe feature was introduced on Sympa 6.2.72. However, some binary distributions including EPEL7 RPM do not support this feature.

Altering message body

  • Message body is altered according to message reception mode chosen by each recipient.

    See "Message reception modes" for details.

  • If message personalization is enabled, message body is altered further.

    See "Message personalization".

Encrypting and signing

  • If DMARC protection is enabled, From header field is consealed.

    See "DMARC protection".

  • If original message has been decrypted (i.e. originally encrypted: See above), re-encryption using certificate of recipient is tried. When it fails, a message to inform failure instead of original message is sent to recipient.

    See "S/MIME" for further details.

  • If DKIM support is enabled, DKIM signature invalidated by alterations so far is removed, then message is signed using Sympa's private key.

    If ARC support is enabled, ARC seal is added using Sympa's private key.

    See "DKIM and ARC features for Sympa".

Eventually, the message is delivered to recipient by the MTA.

Message reception modes

List members can choose the reception mode of their own either through the web interface or via the SET list mode mail command.

The available reception modes can be restricted by listmasters and/or list owners with the available_user_options list/global parameter. list owners can define default reception mode for users added to the list with default_user_options list parameter.

Following changes are made by each mode:

Regular delivery

  • mail: Keeps original content of the message.

  • notice: Keeps only the subject of the message. Message body is entirely removed.

  • txt: Keeps only plain text part of multipart/alternative message. Message content-type is changed from multipart/alternative to text/plain.

  • urlize: Replaces attachments with the links to the file in message archive. This "urlization" depends on the size of each message part: See also urlize_min_size parameter.

  • not_me: Same as mail, however if the recipient is originator of the message, no delivery.

  • nomail: No delivery.

Additionally with mail, not_me, txt or urlize mode, "header" and/or "footer" may be added. They are either added as separate MIME parts, or within the message body if it is of text type. See "Message header and footer").

However, mail and not_me modes do not alter S/MIME signed message (i.e. its MIME type is multipart/signed) so that integrity of signature will not be broken.

Note

  • html reception mode was deprecated on Sympa 6.2.24. Like txt mode, this mode intended to keep only HTML part of multipart messages, and therefore not practically useful.

Digest delivery

If the recipient chooses one of following digest delivery modes, multiple messages are compiled in one message and delivered periodically.

  • digest: Digest delivery (MIME multipart/digest format).
  • digestplain: Digest delivery (plain text format according to RFC 1153).
  • summary: Digest delivery, sort of: Sends the list of links to message archive.

With digest mode, the body of each message compiled in is not altered. the other modes does not keep signature.

However, encrypted messages are never included in compiled message.