Implement SMTP AUTH in Mailman 3

[Patrick Ben Koetter]

Mailman 3 should support sending messages over submission port (587). The Submission RFC (4409, "Message Submission for Mail", http://www.rfc-editor.org/rfc/rfc4409.txt) requires SMTP AUTH, when messages are introduced on submission port.

Currently Mailman does not implement any SMTP AUTH functionality. It looks like Python's smtplib supports PLAIN, LOGIN, and CRAM-MD5. That would be sufficient. Additionally STARTTLS should be implemented to protect credentials when they are sent using either PLAIN or LOGIN.

[Ian Eiloart (iane)]

MSA doesn't require port 587, and some hosts may not support it. A solution would be for Mailman to try port 587 by default - if the connection times out or is dropped, fall back to port 25. The result of the attempt should be cached (per host), so that subsequent deliveries are not delayed. The cache could expire (say daily or weekly) so that changes in the host configuration are picked up, but that might cause deliverability issues if port 587 is opened, but Mailman fails some policy test on the host.

[Barry Warsaw (barry)]

The port that Mailman connects to the upstream SMTP server is already configurable, so I don't think we need to do the probing and caching Ian describes. It looks fairly easy to add a username/password pair for the SMTP connection, and to call .login() if they're set. So I'll add those.

It probably would not be difficult to add keyfile and certfile configuration variables and call SMTP_SSL() when those are given. I'll look at adding that too.

[Barry Warsaw (barry)]

r6972 adds smtp_user and smtp_pass. Please open another bug report if you really want TLS (perhaps with a patch? :).

[Patrick Ben Koetter (p-state-of-mind)]

How does choosing the SASL mechanism work? Does smtplib choose the best (read: most secure) port by itself? I think choosing the SASL mechanism on the client (smtplib) side should be configurable.

[Patrick Ben Koetter (p-state-of-mind)]

Typo in my previous comment: Please replace "port" by "SASL mechanism".

[Barry Warsaw (barry)]

In all honesty, I don't know the details. Looking at the smtplib code in Python 2.6 though, it essentially delegates everything to the socket layer. If the pem/cert files are given, it wraps the socket in an ssl socket, though it only provides a subset of the options available to ssl.wrap_socket(). That's the extent of smtplib's support AFAICT.

Mailman won't support anything the underlying smtplib module doesn't support, so if changes need to happen there, it's best to do that in the context of Python development (though even there, likely nothing will change until Python 3.3 which is a long way off).

[Patrick Ben Koetter (p-state-of-mind)]

* Barry Warsaw <email address hidden>:
> In all honesty, I don't know the details. Looking at the smtplib code
> in Python 2.6 though, it essentially delegates everything to the socket
> layer. If the pem/cert files are given, it wraps the socket in an ssl
> socket, though it only provides a subset of the options available to
> ssl.wrap_socket(). That's the extent of smtplib's support AFAICT.

Erhm, misunderstanding? I wasn't talking about STARTTLS, but the possibility
to control which SMTP AUTH mechnanism will be used.

I took a look at the library and it seems like the library tries to do "the
right thing":

    # List of authentication methods we support: from preferred to
    # less preferred methods. Except for the purpose of testing the weaker
    # ones, we prefer stronger methods like CRAM-MD5:
    preferred_auths = [AUTH_CRAM_MD5, AUTH_PLAIN, AUTH_LOGIN]

CRAM-MD5 is fine, because the identity sent for authentication goes encrypted
over the network. Not so PLAIN or LOGIN. They will only encoded (base64) over
the Net.

We should at least mention in the docs that if MM3 send authentication data
over an unsecured network the submission server on the other end should
support CRAM-MD5. If it does, smtplib will do the right (read: secure) thing.

p@rick

>
> Mailman won't support anything the underlying smtplib module doesn't
> support, so if changes need to happen there, it's best to do that in the
> context of Python development (though even there, likely nothing will
> change until Python 3.3 which is a long way off).
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/490044
>
> Title:
> Implement SMTP AUTH in Mailman 3
>
> Status in GNU Mailman:
> Fix Committed
>
> Bug description:
> Mailman 3 should support sending messages over submission port (587). The Submission RFC (4409, "Message Submission for Mail", http://www.rfc-editor.org/rfc/rfc4409.txt) requires SMTP AUTH, when messages are introduced on submission port.
>
> Currently Mailman does not implement any SMTP AUTH functionality. It looks like Python's smtplib supports PLAIN, LOGIN, and CRAM-MD5. That would be sufficient. Additionally STARTTLS should be implemented to protect credentials when they are sent using either PLAIN or LOGIN.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/mailman/+bug/490044/+subscribe

--
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15 Telefon [phone]
81669 München Telefax [phone]

Amtsgericht München Partnerschaftsregister PR 563

[Patrick Ben Koetter (p-state-of-mind)]

Erhm, misunderstanding? I wasn't talking about STARTTLS, but the possibility to control which SMTP AUTH mechnanism will be used.

I took a look at the library and it seems like the library tries to do "the right thing":

    # List of authentication methods we support: from preferred to
    # less preferred methods. Except for the purpose of testing the weaker
    # ones, we prefer stronger methods like CRAM-MD5:
    preferred_auths = [AUTH_CRAM_MD5, AUTH_PLAIN, AUTH_LOGIN]

CRAM-MD5 is fine, because the identity sent for authentication goes encrypted over the network. Not so PLAIN or LOGIN. They will only encoded (base64) over the Net.

We should at least mention in the docs that if MM3 sends authentication data over an unsecured network the submission server on the other end SHOULD support CRAM-MD5 or SMTP AUTH MAY be eavesdropped. However if it uses CRAM-MD5, smtplib will do the right (read: secure) thing.

[Barry Warsaw (barry)]

How's this (from src/mailman/mta/docs/authentication.txt)

The SMTP server may require authentication. Mailman supports setting the SMTP
user name and password. The actual authentication mechanism used is
controlled by Python's `smtplib module`_, which tries `CRAM-MD5` first,
followed by `PLAIN` and `LOGIN`. When sending authentication data between
Mailman and the MTA over an unsecured network, the submission (mail) server
should support `CRAM-MD5`.

[Patrick Ben Koetter (p-state-of-mind)]

I emphasized a few bits:

The SMTP server may require authentication. Mailman supports setting the SMTP
user name and password. The actual authentication mechanism used is
controlled by Python's `smtplib module`_, which tries the more secure `CRAM-MD5` first,
followed by the less secure mechanisms `PLAIN` and `LOGIN`.

When sending authentication data between Mailman and the MTA over an unsecured network, the submission (mail) server should offer `CRAM-MD5` as mechanism to have Python's `smtplib module` automatically choose the more secure mechanism.

[Barry Warsaw (barry)]

Thanks!