MM developers,
I'd like to propose a change in MM3s default SMTP client port from port 25 (transport) to port 587 (submission).
Why? From my point of view mailman rather is a mail component that introduces messages into a mail system than one that sits between MTAs and assists in transporting messages that pass by.
RFC 4409 <http://www.rfc-editor.org/rfc/rfc4409.txt> explicitly defines a submission port (587) for mail systems whose purpose is to accept message from MUAs:
However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
Apart from doing 'the right thing' what would be the benefit?
The RFC gives some ideas in a later section:
(...) Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality.
From my daily work with mailman the following "modified in some way"-tasks come to my mind immediately:
- apply client and content policy that differs from the port 25 anti-spam policy
- add DKIM signatures because it is clear mailman messages are ORIGINATING from our network
What would we have to do, to make port 587 the default port? In section 4 the RFC says, a MSA MUST do all of the following:
- General Submission Rejection Code
- Ensure All Domains Are Fully-Qualified
- Require Authentication
To cut it short: 1. and 2. are trivial (at least in Postfix and I don't know the others MTAs well enough to tell for them too). 3. requires to add SMTP AUTH functionality to Mailman's SMTP client.
How should we implement SMTP AUTH in the MM SMTP client?
I propose for a start plaintext (PLAIN, LOGIN) and shared-secret mechanisms (CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are the ones used most widely in every day SMTP AUTH.
Later implementations could add GSSAPI and EXTERNAL. If plaintext mechanisms are added we should also consider to add STARTTLS functionality to MM's SMTP client to shield credentials while they are sent in a plaintext authentication session.
p@rick
-- state of mind Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Patrick Ben Koetter writes:
I'd like to propose a change in MM3s default SMTP client port from port 25 (transport) to port 587 (submission).
I don't see a real justification for such a change, given the authentication requirement. While Mailman can be used in relatively closed setups, its central mission remains the more-or-less open discussion list as far as I can see. Closed lists, announcement lists, and the like are very common, but I don't think they are the overwhelming majority of uses yet. Until they are, changing the default is an annoyance to many.
It might be interesting to have both ports open by default, allowing a different policy to be applied to each one.
- Stephen J. Turnbull <stephen@xemacs.org>:
Patrick Ben Koetter writes:
I'd like to propose a change in MM3s default SMTP client port from port 25 (transport) to port 587 (submission).
I don't see a real justification for such a change, given the authentication requirement. While Mailman can be used in relatively closed setups, its central mission remains the more-or-less open discussion list as far as I can see. Closed lists, announcement lists, and the like are very common, but I don't think they are the overwhelming majority of uses yet. Until they are, changing the default is an annoyance to many.
The change I propose is not driven by considerations concerning pro or con open/closed setups. Maybe you misunderstood me or I am misunderstanding your reply.
To clarify: I don't want to require users to authenticate in order to allow them to send. I want mailman to use a stanardized port for message submission (and that brings in the authentication requirement).
Everybody seems to use a dedicated port to inject messages coming from mailman. People do that either to completely avoid applying expensive content filter rules to all messages coming from mailman or they do it to only run a minimal subset of content filter rules.
I want to standardize that dedicated port and I propose to use the submission port as recommended by RFC for scenarios like that. The authentication requirement applies to the mailman server (read: SMTP client) only. It can be set once in the global mailman configuration file. Users don't need to do anything. It's completely transparent to them.
p@rick
-- state of mind Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Patrick Ben Koetter writes:
To clarify: I don't want to require users to authenticate in order to allow them to send. I want mailman to use a stanardized port for message submission (and that brings in the authentication requirement).
Oh, so this is outgoing? Now I see.
I still don't think it's a good idea until we've checked that most popular OS distros supply all their MTAs configured to accept on port 587, and we had better have a bullet-proof autoconfigurator for it. MTA issues are the biggest FAQ that we don't have a good canned answer for, and this is not going to make them fewer without a lot of "cooperation" from MTA packagers.
On this family-oriented channel, I think it is best not to describe the pain this will cause cPanel and Plesk clients.
On Nov 29, 2009, at 8:55 PM, Stephen J. Turnbull wrote:
I still don't think it's a good idea until we've checked that most popular OS distros supply all their MTAs configured to accept on port 587, and we had better have a bullet-proof autoconfigurator for it. MTA issues are the biggest FAQ that we don't have a good canned answer for, and this is not going to make them fewer without a lot of "cooperation" from MTA packagers.
That would be good to know. Maybe someone would like to contribute a
script that did a bit of probing and spit out a sample configuration
file?
On this family-oriented channel, I think it is best not to describe the pain this will cause cPanel and Plesk clients.
IWBNI those folks would engage with us early (or, hmm, at all?) so
that we could at least understand their requirements.
-Barry
--On 29 November 2009 21:07:28 -0500 Barry Warsaw <barry@python.org> wrote:
On Nov 29, 2009, at 8:55 PM, Stephen J. Turnbull wrote:
I still don't think it's a good idea until we've checked that most popular OS distros supply all their MTAs configured to accept on port 587, and we had better have a bullet-proof autoconfigurator for it. MTA issues are the biggest FAQ that we don't have a good canned answer for, and this is not going to make them fewer without a lot of "cooperation" from MTA packagers.
That would be good to know. Maybe someone would like to contribute a script that did a bit of probing and spit out a sample configuration file?
Autoconfiguration shouldn't be too hard. Mailman has to be configured with a hostname. There are three options for the port:
custom configuration 587 25
Mailman can test the connectivity of each in turn, on the first message that it sends. Cache the port number on success. This should be run-time autoconfiguration, not install time autoconfiguration. That way, the configuration can cope with a change of host name. If a port becomes unavailable, then alternate ports could be tested...
Other mail clients do this, including Apple Mail and MS Outlook, when configuring new accounts.
Am I right in thinking that all the mail is typically routed through a local MTA?
On this family-oriented channel, I think it is best not to describe the pain this will cause cPanel and Plesk clients.
IWBNI those folks would engage with us early (or, hmm, at all?) so that we could at least understand their requirements.
-Barry
-- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/
On Nov 30, 2009, at 6:28 AM, Ian Eiloart wrote:
Autoconfiguration shouldn't be too hard. Mailman has to be
configured with a hostname. There are three options for the port:custom configuration 587 25
Mailman can test the connectivity of each in turn, on the first
message that it sends. Cache the port number on success. This should
be run-time autoconfiguration, not install time autoconfiguration.
That way, the configuration can cope with a change of host name. If
a port becomes unavailable, then alternate ports could be tested...Other mail clients do this, including Apple Mail and MS Outlook,
when configuring new accounts.Am I right in thinking that all the mail is typically routed through
a local MTA?
Yes. I should also say that I think adding support for AUTH (via
smtplib.SMTP.login()) is somewhat orthogonal to port selection. We
should do the former even if we change nothing about current port
selection.
Here's a thought on the latter for anybody wishing to hack: extend the
semantics of [mta]smtp_port in Mailman 3 to allow for a list of
whitespace separated ports to try, and add a cache_lifetime
parameter. If int(config.mta.smtp_port) fails, try splitting the
variable and int'ing the items. In that case, try each port in order
and remember the winner for cache_lifetime. You don't need to keep
the cached value in the db; it would be fine to throw it away and re-
probe on outgoing queue restart.
In the new tradition of the 21st century: branches welcome. :) If
someone does want to contribute here, please make the AUTH support a
separate branch from the port probe support. I will be happy to
review any such branches.
-Barry
On Nov 29, 2009, at 4:30 AM, Patrick Ben Koetter wrote:
What would we have to do, to make port 587 the default port? In
section 4 the RFC says, a MSA MUST do all of the following:
- General Submission Rejection Code
- Ensure All Domains Are Fully-Qualified
- Require Authentication
To cut it short: 1. and 2. are trivial (at least in Postfix and I
don't know the others MTAs well enough to tell for them too). 3. requires to
add SMTP AUTH functionality to Mailman's SMTP client.How should we implement SMTP AUTH in the MM SMTP client?
I propose for a start plaintext (PLAIN, LOGIN) and shared-secret
mechanisms (CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are
the ones used most widely in every day SMTP AUTH.Later implementations could add GSSAPI and EXTERNAL. If plaintext
mechanisms are added we should also consider to add STARTTLS functionality to
MM's SMTP client to shield credentials while they are sent in a plaintext
authentication session.
Should we decide to do this, changing the port number is easy.
There's already a configuration variable for this (currently set of
course to 25).
As for implementing SMTP AUTH, we are limited by what Python's smtplib
supports. From a cursory inspection of the module in Python 2.6, it
looks like it supports PLAIN, LOGIN, and CRAM-MD5. That may mean that
the only thing we need to add to Mailman is plumbing for setting the
user name and password in the config file.
Please open a bug on the Mailman project in Launchpad for this.
-Barry
- Barry Warsaw <barry@python.org>:
On Nov 29, 2009, at 4:30 AM, Patrick Ben Koetter wrote:
What would we have to do, to make port 587 the default port? In section 4 the RFC says, a MSA MUST do all of the following:
- General Submission Rejection Code
- Ensure All Domains Are Fully-Qualified
- Require Authentication
To cut it short: 1. and 2. are trivial (at least in Postfix and I don't know the others MTAs well enough to tell for them too). 3. requires to add SMTP AUTH functionality to Mailman's SMTP client.
How should we implement SMTP AUTH in the MM SMTP client?
I propose for a start plaintext (PLAIN, LOGIN) and shared-secret mechanisms (CRAM-MD5, DIGEST-MD5) should be added to the SMTP client. Those are the ones used most widely in every day SMTP AUTH.
Later implementations could add GSSAPI and EXTERNAL. If plaintext mechanisms are added we should also consider to add STARTTLS functionality to MM's SMTP client to shield credentials while they are sent in a plaintext authentication session.
Should we decide to do this, changing the port number is easy. There's already a configuration variable for this (currently set of course to 25).
As for implementing SMTP AUTH, we are limited by what Python's smtplib supports. From a cursory inspection of the module in Python 2.6, it looks like it supports PLAIN, LOGIN, and CRAM-MD5. That may mean that the only thing we need to add to Mailman is plumbing for setting the user name and password in the config file.
Sounds like a thing rather easily done.
Please open a bug on the Mailman project in Launchpad for this.
done. <https://bugs.launchpad.net/mailman/+bug/490044>
p@rick
-- state of mind Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
- Patrick Ben Koetter <p@state-of-mind.de>:
From my daily work with mailman the following "modified in some way"-tasks come to my mind immediately:
- apply client and content policy that differs from the port 25 anti-spam policy
- add DKIM signatures because it is clear mailman messages are ORIGINATING from our network
I seem to remember a certain training where the two of us were showing some very different ways on how to deal with individual policies ;-)
I don't think changing the default port would be such a great idea. The submission port is widely used for messages submitted by _end users_ - with all the necessary precautions in place, i.e. DNS checks, SMTP AUTH and content filtering (at least virus filtering).
MM generated messages don't need DNS or virus checks - the messages were already scanned when they entered the system, and temporary rejects on DNS errors are detrimental to MM's bounce recognizing abilities. There's a high probability you'd have to create a SMTP listener with a dedicated policy set anyways - changing SMTPPORT in mm_cfg.py is only a very minor task in setting up a mailing list server.
Cheers Stefan
participants (5)
-
Barry Warsaw -
Ian Eiloart -
Patrick Ben Koetter -
Stefan Förster -
Stephen J. Turnbull