[Biopython] Support for Xdna, SnapGene and GCK formats

Thu Aug 1 12:19:21 UTC 2019

On Thu, Aug 01, 2019 at 10:01:22AM +0100, Peter Cock wrote:
>> All the GCK files I have come from the "Drosophila Gateway Vector
>> Collection" [1]; those files are not explicitly released under any free
>> license (in fact there are no license terms at all), so I don't think we
>> could bundle even one of them with the Biopython's source code, even if
>> it is just to serve as a test file.
>
>The website [1] had a fairly liberal copyright statement at the bottom,
>suggesting a sample file could be used with attribution (e.g. in the git
>check in comment and where the test or example code used it)?

The notice states "You are free to use the information contained on this 
page for non-profit purpose [...]". I am not sure this would be 
compatible with either the 3-clause BSD license or the Biopython License 
Agreement (neither of them excluding any kind of for-profit use).

I am also slightly concerned by the following statement: "Portions of 
the material contained in the Drosophila Gateway Vector collection are 
subject to international patents [...]". I guess this refers to the 
vectors themselves and not merely to files containing their sequences, 
but I wonder if that could be subject to interpretation.

Obviously I am no lawyer, so maybe I am just worrying too much. :)

>Damien, you evidently know a lot more about email headers etc than me.
>Are you also familiar with mailman, and how it might be better configured
>on this specific point?

Yes.

Basically there's two options.

a) Avoid modifying the original message. That is, do not add the 
"[Biopython]" tag in the Subject header, and do not add a footer.

This way the original DKIM signature emitted by the sender remains 
valid.

This is probably the easiest solution. Unfortunately, it implies to give 
up on what most people have come to see as standard features of mailing 
lists since almost the beginning of the Internet, like the footer with 
the links to the mailing list archives or the unsubscribing options (the 
RFC 2369 [1] is actually a better way of providing such informations, 
but it requires explicit support from the mail client).

To implement this approach, what needs to be done in Mailman's 
configuration is to make sure the `subject_prefix`, `msg_header`, and 
`msg_footer` settings are left empty.

b) The mailing list "takes ownership" of the message. That is, the 
mailing list software has to change the "From" header so that the 
message appears to come from the mailing list domain instead of the 
domain of the original sender.

This way, a DMARC-compliant mail server will not attempt to validate the 
DKIM signature emitted by the original sender, so it will not matter 
that the message has been modified in any way.

With Mailman this can be done in two ways:

* set the `from_is_list` setting to `Munge From`, or

* set the `dmarc_moderation_action` to `Munge From`.

Both settings have the same effect. The difference between them is that 
`from_is_list` applies to *all* messages, whereas 
`dmarc_moderation_action` only applies to messages coming from a domain 
with a strict DMARC policy. As far as I know Mailman developers 
recommend the latter.

Unfortunately, `from_is_list` has been introduced in Mailman 2.1.16 and 
`dmarc_moderation_action` in Mailman 2.1.18, but mailman.open-bio.org is 
running Mailman 2.1.15, so an upgrade would be needed before we can 
adopt that approach.

>We (the OBF) intend to migrate the current self hosted mailman instance
>to paid hosting in part because we don't have enough volunteer administrators
>to keep in top condition - sadly even making that happen requires a large
>chunk of time from a handful of the existing team and hasn't happened yet:
>
>https://www.open-bio.org/2017/12/15/mailing-list-consolidation/

As an amateur sysadmin myself, knowing what it takes to maintain even a 
small service, I feel your pain. :)

Cheers,

- Damien

[1] https://www.ietf.org/rfc/rfc2369