[Mailman-Developers] New RFC on using DKIM with MLMs

Wed Nov 16 17:10:03 CET 2011

On 11/15/2011 6:52 PM, Barry Warsaw wrote:
> On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote:
>
>> I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598
>> <http://www.rfc-editor.org/in-notes/rfc5598.txt> instead:
>>
>>   A Mediator attempts to preserve the original Author's information in
>>   the message it reformulates but is permitted to make meaningful
>>   changes to the message content or envelope.
>>
>>   A Mediator's role is complex and contingent, for example, modifying
>>   and adding content or regulating which Users are allowed to
>>   participate and when.  The common example of this role is a group
>>   Mailing List.
>>
>>   (see section "2.1.4. Mediator" and also section "5. Mediators")
> That makes a good case for Mediator.

Hmmm.  To me, the above definition for Mediator is reason enough to
abandon it (for the time at least) because it is not well thought out
regarding everything that may touch, modify, add content, regulate user,
etc.   Together with the above and a line from a previous message
Patrick sent to the list:

           "The term 'Mediator' describes the same, but it is general in
meaning. Any instance modifying and forwarding a message can use it. "

I can't help but consider the rash of useless Mediator headers.
Consider the following example:

Person 1 sends a message to a list which is then sent to Person 2.
Person 1's site has separate appliances for the MTA, Spam checking,
Anti-Virus, and Spy-ware, likewise for the receiver's site and the site
the MLM is for the list.  My reading of the above definitions tells me:
1. Person 1's MUA adds a Mediator header (creating a message is a simple
special case of modifying/adding a message,
2. Person 1's site adds 4 additional Mediator headers (one each for the
MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the
message,
3. The MLM's site adds 9 additional Mediator headers (4 inbound [item
2], 1 for the MLM [maybe more], and 4 outbound),
4. Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]),
5. Person 2's MUA may or may not add a Mediator header depending on any
rules/filters Person 2 has in place.

So, at the end of this simple posting of a message to a list, we have
18+ Mediator headers, one for each time an instance adds content,
modifies a message, or regulates a user.

Granted, I may be making this a worst case scenario, but also consider
any sites the message is relayed through - adding even more Mediator
headers.  Looking at a worst case scenario helps see where the problems
occur and cracks in specifications happen.

I am not opposed to a Mediator header.  I just think since our
discussion is focused on MLMs that List-Agent is the best choice that
all MLM developers can come to an agreement on.

As for other applications (news, web forum, etc), a discussion with
those developers should (and needs to) take place to come up with a more
generic header - be it Mediator or not.

In any case, let's focus on MLM related headers, like List-Agent :), and
then work on a more generic, non-conflicting header for others at a
later time.   I just see including non-MLM information into a MLM header
discussion as feature-creep.

>> Hmm, if there are no intermediate processes between receiving a message and
>> approving it a List-Approved-Date seems fine. But if there are we run into the
>> same problem as described below with List-Archived-Date - you can't tell when
>> it was queued and when processing took place.
>>
>> Adding a second header might make the useful distinction:
>>
>> List-Received-Date
>>        RFC 2822 date timestamp when message was received by MLM
>>
>> List-Approved-Date
>>        RFC 2822 date timestamp when message was approved by moderator
> What if the message is automatically approved?  Does it get a
> List-Approved-Date header?  Merging with Murray's concept of Received states,
> it might just make more sense to put all that information into Received
> headers.

The only issue I can see is if the Received headers are removed as part
of processing, whether in an appliance, an MTA, or an MUA.  I know it
shouldn't happen but I received messages with missing Received headers.
Having the information in a List-* header wouldn't hurt.

>
>>> Another header that might be useful here would be List-Approved-By which
>>> could be the name or email address of the moderator who approved it.  Right
>>> now, MM3 doesn't fill that in, and it could of course be filled in by say
>>> list-owner at example.com, but in MM3 it could be potentially filled in with
>>> the preferred address for the moderator that approved it.
>> I see the benefit because it helps if you moderate in a team. But I fear the
>> anger of people whose postings we decline. They search for moderator
>> identities and then start molesting them e.g. by subscribing them to mailing
>> lists that don't require opt-in. (Happend to me python.org postmaster. The
>> angry person subscribed my address to various pr0n mailing lists and it took
>> me weeks to get unsubscribed.)
> Good point.  I do want to provide the opportunity to "anonymize" ownership
> roles via generic owner email addresses.  E.g. on the listinfo page.

:) So far, I haven't had anyone that grumpy at me to add me to various
"other" lists.  But they do occasionally go over my head to get
authorization so they can post without being moderated (at least until
they send a message that exceeds the size limit).

>
>> ACK with the notion that hashtag seems to closely realted with twitter and a
>> more general 'tag' would stay away from that.
>>
>> Is there or should there be a distinction between 'tag' and http 'keywords'
>> <http://en.wikipedia.org/wiki/Meta_element#The_keywords_attribute>? Should we
>> use 'keywords' instead?
> We can't use Keywords, because that header is already used as input to various
> functions such as the topic tagger.  We have to use a different header for
> "output".  I can't think of anything better than List-Tags though.
>
>> List-Archive-Send-Date
>>        'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we
>>        needn't care, as it will only be added to messages that go to the
>>        archive, right?
>>
>> Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer
>>        Marks the beginning in opposition to Archive-Received-Date or
>>        Archive-Received. But then again an archiver could simply add a
>>        Received:-header!
>>
>> Not an easy one.
> Agreed. :/
>
> -Barry
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/cnulk%40scu.edu
>
> Security Policy: http://wiki.list.org/x/QIA9

Thanks for bearing with me,
Chris