Skip to Content.
Sympa Menu

Documentation for Sympa

NAME

Sympa::Message - Mail message embedding for internal use in Sympa

SYNOPSIS

use Sympa::Message;
my $message = Sympa::Message->new($serialized, context => $list);

DESCRIPTION

While processing a message in Sympa, we need to link information to the message, modify headers and such. This was quite a problem when a message was signed, as modifying anything in the message body would alter its MD5 footprint. And probably make the message to be rejected by clients verifying its identity (which is somehow a good thing as it is the reason why people use MD5 after all). With such messages, the process was complex. We then decided to embed any message treated in a “Message” object, thus making the process easier.

Methods and functions

Context and Metadata

Context and metadata given to constructor are accessible as hash elements of object. These are typically used.

Attributes

These are accessible as hash elements of objects.

Serialization

Sympa::Message object includes number of slots as hash items: metadata, context, attributes and message content. Metadata including context are given by spool: See “Marshaling and unmarshaling metadata” in Sympa::Spool.

Logically, objects are stored into physical spool as serialized form and deserialized when they are fetched from spool. Attributes will be serialized and deserialized along with raw message content. Attributes are encoded in X-Sympa-*: pseudo-header fields and Return-Path: header field. Below is an example of serialized form.

X-Sympa-Message-ID: 123456789.12345@domain.name : {message_id} attribute
X-Sympa-Sender: user01@user.sympa.test          : {sender} attribute
X-Sympa-Display-Name: Infant                    : {gecos} attribute
X-Sympa-Shelved: dkim_sign; tracking=mdn        : {shelved} attribute
X-Sympa-Spam-Status: ham                        : {spam_status} attribute
Return-Path: sympa-request@domain.name          : {envelope_sender} attribute
Message-Id: <123456789.12345@domain.name>       :   ---
From: Infant <user@other.host.dom>              :    |
To: User <user@some.host.name>                  :    |
Subject: Howdy world                            :    | Raw message content
X-Sympa-Topic: sometopic                        :    |
                                                :    |
Bonjour, le monde.                              :    |
                                                :   ---

On msg, automatic and bounce spools, Return-Path: header fields are given by MDA and X-Sympa-*: header fields are given by queue programs. On other spools, they are given by components of Sympa.

Pseudo-header fields should appear at beginning of serialized content. Fields appear at other places (e.g. X-Sympa-Topic: field above) are not attributes but are the part of raw message content.

Pseudo-header fields should not be included in actually sent messages.

CAVEAT

Adding Return-Path: field

We trust in Return-Path: header field only at the top of message to prevent forgery. To ensure it will be added to messages by MDA,

BUGS

get_plaindigest_body() seems to ignore any text after a UUencoded attachment.

HISTORY

Message module appeared on Sympa 3.3.6. It was initially written by:

get_plaindigest_body, ex. “plain_body_as_string” in PlainDigest, was initially written by Chris Hastie. It appeared on Sympa 4.2b.1.

(c) Chris Hastie 2004 - 2008.

Renamed and merged Sympa::Message appeared on Sympa 6.2.

Top of Page