Hi all,
I noticed (from a DMARC mitigation utility that Lindsay extracted) that Mailman
features its own approach to using the PSL. Of course, development must go on,
and sometimes it is a waste of time trying to make a super-duper scaffolding
for a job that can be carried out complying to the KISS principle. At any
rate, what is the future of DMARC lookups in Mailman?
* The specs say that "DMARC should be amended to use [a method better than PSL]
as soon as it is generally available" [1]. I believe that sentence refers to
RDAP, which was released more or less at the same time (March 2015) [2].
[1] https://tools.ietf.org/html/rfc7489#appendix-A.6
[2] https://datatracker.ietf.org/wg/weirds/documents/
* There are various Python packages for domain name splitting. They obviously
use the PSL, but supposedly would transparently switch to a better method in
case. If Mailman used one such package, a practical advantage for users would
be to update the PSL in only one place, if they happened to use the same
dependency. I found six packages.
tldextract [3] is the only one of them which caches a JSON object rather than
the original textual representation of the list. It uses a frozenset. tld [4]
and publicsuffixlist [5] also build a set. publicsuffix[6] and publicsuffix2
[7] build lists of nested dictionaries from all the labels. dnspy [8] builds a
dictionary of FQDNs, somewhat like Mailman.
How does the time to build the structure compare with the time taken by DSN
queries?
[3] https://pypi.python.org/pypi/tldextract
[4] https://pypi.python.org/pypi/tld
[5] https://pypi.python.org/pypi/publicsuffixlist
[6] https://pypi.python.org/pypi/publicsuffix
[7] https://pypi.python.org/pypi/publicsuffix2
[8] https://pypi.python.org/pypi/dnspy
* Debian distributes a publicsuffix package which brings a textual version of
the list. Since stretch, it also brings a "dafsa" version. Nowadays, most C
implementations (Firefox, Chromium) use dafsa. They build the structure using
offsets rather than pointers, so that the blob can be defined in a source file
as a literal static array of chars, in order to minimize loading time. That
strategy works well as long as the relevant package is upgraded more frequently
than the PSL. Otherwise, as for libpsl, one ends up using obsolete data.
Surprisingly, the publisuffix package itself is not upgraded as frequently as
the PSL. This bug [9] is what prompted me to write this message. I guess you,
as Mailman developers, have pondered this subject and I'd be interested to know
what you think.
[9] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879008
TIA for any reply
Ale
--
On Oct 24, 2017, at 16:52, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>
> Gitlab now supports verification of commit signatures and it would be
> awesome if we start signing commits. It is a relatively painless process
> and happens automatically with little configuration.
Very cool that GL has enabled this! Thanks for sending the recipe too. I definitely encourage folks (especially core devs) to start signing commits.
Cheers,
-Barry
Hi All,
Gitlab now supports verification of commit signatures and it would be
awesome if we start signing commits. It is a relatively painless process
and happens automatically with little configuration.
Spoofing authors in git is quite easy, actually provided as a command
line option (--author, --reset-author), and I believe it would be a good
practice to sign all the commits (even outside of Mailman).
Here are steps for how you can do that:
1. Add your public key to Gitlab (https://gitlab.com/profile/gpg_keys)
2. Commit with `-S` (capital S)
Here is the relevant section of `.gitconfig` to auto-sign every commit
you make (no need for step 2 if you do this):
```
[user]
name = Abhilash Raj
email = raj.abhilash1(a)gmail.com
signingkey = 541EA0448453394FF77A0ECC9D9B2BA061D0A67C
[commit]
gpgsign = true
```
Once you have pushed a signed commit to Gitlab and have uploaded your
gpg public key, you will see a green "Verified" button alongside every
commit. (See
https://gitlab.com/maxking/mailman/commits/msapiro/mailman-pending)
--
Abhilash Raj
maxking(a)asynchronous.in
On 10/23/2017 05:02 PM, Abhilash Raj wrote:
> On Mon, Oct 23, 2017, at 08:59 AM, Barry Warsaw wrote:
>> On Oct 23, 2017, at 11:48, Aurelien Bompard <aurelien(a)bompard.org> wrote:
>>>
>>> I wanted to rename a list (only the list_name, not the list_id) and I
>>> figured I would make the transition smoother by adding an "AcceptableAlias"
>>> with the old name. I did that and realized that the acceptable aliases are
>>> not added to the postfix_lmtp file, as a result emails sent to the old
>>> address are just bounced at the Postfix level.
>>> Is this the intended behavior ?
>>
>> It is. The thinking is that whatever email addresses end up funneling to
>> a list is really outside of Mailman’s control. That’s really part of
>> your MTA’s configuration, and acceptable aliases are just a way of
>> telling Mailman to expand its implicit address logic.
>
> As I understand, AcceptableAliases are defined as regular expressions,
> what if Mailman put the values that are a valid list name to
> transport_maps? Converting regex to a listname doesn't sound like a
> straight forward thing to me though.
I think that's going to be too complex and error prone.
> This most definitely adds some complexity for unique checks of
> Listnames. I am not sure if we already check acceptable alias rules for
> existing mailing lists to make sure they don't match any new list
> created. We'd have to do it if we start putting acceptable aliases in
> transport maps.
We don't and it doesn't matter for what acceptable_aliases is intended
to be used for.
The background is a list can be configured (and is by default) to
require_explicit_destination. which is intended as an anti-spam measure.
I.e. it requires the list posting address to appear in To: or Cc: of
the message and stops "To: undisclosed recipients:;" type of mail.
> As a feature, it could be helpful to have multiple posting addresses for
> a single List. Are there any major downsides to doing this?
You can, either by aliases, .forwards or other MTA type configurations.
And that's exactly what acceptable_aliases is for - to accept those
alternate posting addresses as valid explicit destinations.
But, I think it should be up to the installation to configure their MTAs
or whatever for this. I don't thing we should be trying to generate MTA
configurations for alternate list names bases on acceptable_aliases.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
On Oct 23, 2017, at 11:48, Aurelien Bompard <aurelien(a)bompard.org> wrote:
>
> I wanted to rename a list (only the list_name, not the list_id) and I
> figured I would make the transition smoother by adding an "AcceptableAlias"
> with the old name. I did that and realized that the acceptable aliases are
> not added to the postfix_lmtp file, as a result emails sent to the old
> address are just bounced at the Postfix level.
> Is this the intended behavior ?
It is. The thinking is that whatever email addresses end up funneling to a list is really outside of Mailman’s control. That’s really part of your MTA’s configuration, and acceptable aliases are just a way of telling Mailman to expand its implicit address logic.
> BTW, changing the list_name attribute is sufficient to rename a list,
> right? I didn't find anything else to change since everything seems to be
> keyed to the list_id but I thought I'd check with you.
Correct. List name is mutable but list-id is not, even if you move it to a different domain!
-Barry
Hey folks!
I wanted to rename a list (only the list_name, not the list_id) and I
figured I would make the transition smoother by adding an "AcceptableAlias"
with the old name. I did that and realized that the acceptable aliases are
not added to the postfix_lmtp file, as a result emails sent to the old
address are just bounced at the Postfix level.
Is this the intended behavior ?
BTW, changing the list_name attribute is sufficient to rename a list,
right? I didn't find anything else to change since everything seems to be
keyed to the list_id but I thought I'd check with you.
Thanks!
Aurélien
Mark, et al
While configuring the MM 2.1 DMARC mitigation code for use in Courier-
MTA I note that the return from _DMARCProhibited(..) for a detected
policy of "p=none" is True, just as it is for "p=quarantine" and
"p=reject". Why is this? I would assume that if this code is reached,
and p=none, that no From munging would be required.
--
Lindsay Haisley | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190 |
http://www.fmp.com | -- Hiram W Johnson
Hey folks, This is a request for a pointer to some code rather than an
offering for Mailman, but I hope my cred with the Mailman developers
will fetch me a bit of help. I can read code and find this out myself,
but one of the Mailman devs can probably give me some pointers that
will save me a lot of time, time being the only human resource which is
truly limited!
I'm running Courier-MTA, an excellent MTA around which I've built FMP's
small ESP services. Courier has the ability to do a simple email
redirect using an alias address in a flat file, in a special directory,
containing only the email address to which email should be redirected.
Courier also has the ability to interpret lines in this file starting
with "|" as programs to which the body of an email can be submitted via
stdin and any required processing done therein. I'm the author of
courier-to-mailman.py in the contrib collection in Mailman 2's current
standard code which works this way.
I'm seeing increasing problems with DMARC rejection of emails sent
through this simple redirection mechanism, for obvious reasons, and I'm
thinking that I might borrow code from Mailman to re-write the From
address just as Mailman does when handling a list with from_is_list set
to "Munge From", and then pipe emails for selected ESP clients through
this filter. Said filter must:
* detect whether or not the sending domain publishes a DMARC "p=reject"
or "p=quarantine" record
* If so, parse out the From address in the email and rewrite it in the
general form Mailman uses with "on behalf of ..." giving the origianl
sender and specifying the mail server's DN in the sender address.
... after which the email will be sent on to the recipients _real_
address. The management of the message body, the piping and such is
handled quite well by Courier.
I assume that this would mitigate the DMARC issue for redirections
through our mail server, just as it does for Mailman.
So, if someone could give me a few pointers to the relevant code in
Mailman 2, and any suggestions which might save me some time, I can
take it from there. I'm python-literate and have hacked our copy of
Mailman here in the past - perhaps more than is wise since every time I
upgrade I need to apply a number of patches to bring my mods along with
the upgrade :)
Thanks for any help you can give me. If it's too much bother, tell me
so and I'll put on my hacker's hat and go read code :)
Ciao,
--
Lindsay Haisley | "Behold! Our way lies through a
FMP Computer Services | dark wood whence in which
512-259-1190 | weirdness may wallow!”
http://www.fmp.com | --Beauregard
What's the state for Centos? I think it was the last likely distro we cared about with old python needs, but I'm not sure core supports it at all any more.
On October 1, 2017 2:12:46 PM PDT, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>Hi All,
>
>Mailman uses Django web framework for the web based frontends,
>Postorius
>- The Official UI, and Hyperkitty - The official Archiver. They are
>both
>Django "apps" which means that they can be plugged into any other
>existing Django "project" (aka Django "installation") to work alongside
>other apps that people might be running.
>
>Currently, both the Django apps we have are Python 2 only, we have
>talked about moving to Python 3 but we decided we want it to be
>bilingual (support both 2 & 3). The reason we decided that was because
>if people would want to embed Postorius & Hyperkitty in their
>installations, they need to be able to run it under whatever python
>versions they are using.
>
>I want to revisit this assumption for being bilingual. Currently, there
>is no supported version of Django which doesn't support Python 3.
>Starting from v2.0, set to release in December 2017, Django is going to
>drop Python2 support. Now, that doesn't mean no one can run Django
>under
>Python2, 1.11 (LTS version) supports Python2 and will be supported
>probably till Python 2 is supported (April 2020 according to [1]).
>
>I believe that our (limited) development efforts would be best utilized
>if we just drop the support for Python 2 in Postorius & Hyperkitty
>instead of trying to be bilingual. Any day one of our dependencies may
>decide to do the same, and we would have to then use Python 3 anyway.
>Also, dropping Python 2 support doesn't seem like a lot of pain for
>anyone, you just need another instance of Django running, which is not
>*that* hard using uwsgi (in Emperor mode). I believe most of our
>dependencies should support Python 3, or should have a good enough
>replacement if it doesn't.
>
>
>Thoughts?
>
>[1]: https://www.djangoproject.com/download/
>
>--
> Abhilash Raj
> maxking(a)asynchronous.in
>_______________________________________________
>Mailman-Developers mailing list
>Mailman-Developers(a)python.org
>https://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:
>https://mail.python.org/mailman/options/mailman-developers/terri%40toybox.ca
>
>Security Policy: http://wiki.list.org/x/QIA9
