Skip to Content.
Sympa Menu

en - RE: [sympa-users] Why ist there "-request" and "at request of" in the From-address, in mailings received by members?

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Steve Shipway <address@concealed>
  • To: "Tomaschewski-Walser Doris (ID SDL)" <address@concealed>, "address@concealed" <address@concealed>
  • Subject: RE: [sympa-users] Why ist there "-request" and "at request of" in the From-address, in mailings received by members?
  • Date: Mon, 25 Aug 2014 23:18:04 +0000

> In my case, the senders are all members of the list and send direct mail
to the
> list, without doing a "reply to all".
> When such mail is received by non-Microsoft mail clients, the messages do
> indeed NOT show this addition of <-request > and "on behalf of" in the
> From-address.
> The same messages DO show these additions in MS Outlook and Outlook
> Webaccess.

As previously mentioned, Outlook is spotting the Sender header and treating
it as a 'secretary scenario'.

I think, technically, Sympa *is* acting like a secretary -- sending out the
bulk email on behalf of the originator. Thus, Sympa is using the Sender
header correctly, according to the definition in the RFC, to indicate the
account that injected the email into the system, whereas the From header
indicates the ultimate source of the message. This is supposedly to allow
mail systems to validate the incoming route against Sender (when present)
but still display the From address as the source of the message.

Sadly, this is not always correctly handled by mail clients; for example,
DMARC incorrectly validates against From even if Sender is present, and
Outlook gives it undue prominence in the display "From $Sender on behalf of
$From". While this is true, if Tracy sent an email on behalf of her boss
Cressida, I'd rather see "From Cressida (via Tracy)". In your case, Sympa
is Tracy...

Since the only options are (a) wait until Microsoft does it the way you
want, (b) work around their behaviour, or (c) ignore it -- and we all know
option (a) is never going to happen. It would seem your only options would
be to either remove the Sender header (using the Sympa
remove_outgoing_header option), or to make the Sender header have a display
name that is more helpful, such as "Mailing List
(address@concealed)".

Removing the outgoing Sender header risks breaking SIDF checks (if your
mailing list posters are outside of your organisation), though DMARC has
already broken this by ignoring Sender entirely.

Sympa 6.1.19 sets Sender in List.pm around line 3070 but does not give the
option to add a display name. This change adds a display name to the Sender
header (a proper patch should allow the display name to be configurable
per-list):

$hdr->add('Sender',
Mail::Address->new("Mailing List",
"$self->{'name'}-request\@$self->{'admin'}{'host'}"
)->format
);

... however, Outlook will still display the sender email address as follows:

Mailing List <address@concealed> on behalf of Steve
Shipway <address@concealed>

I'm not aware of the Matthies patch referred to by Olaf Menkens in the
previous message so I don't know what he proposed.

You could set the Sender header to just "Sender: Sympa" (with no valid email
address) which would display more clearly in Outlook, but it would break the
RFC and any correctly-defined SIDF validators (that validate against Sender
if present, instead of From) -- plus, if you're doing this, you may as well
remove the header entirely.

My personal feeling is to leave things the way they are. Sympa is using the
Sender header correctly as per the RFC; since Sympa is effectively being
your secretary for the purpose of distributing this message, then
Microsoft's interpretation of the header is technically correct, although
(IMHO) they give too much prominence to the 'secretary' name at the expense
of the Originator's name. In any case, this is a user-agent display issue
rather than a bug in Sympa, and bending or breaking Sympa's RFC-compliance
to accommodate Microsoft's eccentricities is likely to break other things in
the future, and there is no guarantee that Microsoft won't change their mind
in the next release and do something different again.

Steve

Steve Shipway
address@concealed


Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.19+.

Top of Page