[ClusterLabs] Fraud Detection Check?

[Jan Pokorný]

On 13/04/17 08:21 +0200, Jan Pokorný wrote:
> On 12/04/17 17:16 -0500, Dimitri Maziuk wrote:
>> On 04/12/2017 04:36 PM, Jan Pokorný wrote:
>> 
>>> Eric, as of now, to get rid of the fraud warnings, it's primarily your
>>> emailing software that needs to be taught to be less picky either when
>>> sending, i.e., also DKIM signing the message to clusterlabs.org, or when
>>> receiving (and DKIM verifying) the slightly changed copy from there.
>>> It's in your hands, good luck.
>> 
>> No, and that's one of the reasons for my earlier "doesn't everyone"
>> quip, although this particular idiocy is not limited to orifice'365.
>> 
>> This message is an example of how to do it right. (The mime part that is
>> signed does not get altered by adding the mime part with list footers.)
>> DKIM is the example of how to do it wrong *after* we worked out the way
>> to do it right.
> 
> Oh, learned something new, presumbly because MTAs I use won't bother
> with DKIM signing (that I'd be aware of) for my outgoing post and
> my MUA itself hardly cares about verification of incoming, so never
> faced any such issue.  And agreed, GPG signing with the key associated
> with the email address of the sender should be perfectly sufficient
> for authenticity check in most of the cases.
> 
> Thanks for a bit of clarification.

After a bit of a search, the best practice at the list server seems to
be:

> [...] if you change the message (eg, by adding a list signature or
> by adding the list name to the Subject field), you *should* DKIM
> sign.

(https://mail.python.org/pipermail/mailman-users/2015-June/079303.html)

Alternative is to strip DKIM headers completely there, but there are
reasons against that stated at
https://bugs.launchpad.net/mailman/+bug/557493

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20170413/e76e37ed/attachment.sig>