Dear all, I recognize that mailman can accept a fake sender . Example, I have a maillist with only an email account (xyz@abc.com) can send messages to all emails in the list. But , if someone can send a fake "From address" is xyz@abc.com, mailman will delivery messages to the list . This is a security problem. Can we prevent this from happening ? Best regards, Huu Hien
Hien HUYNH HUU writes:
I recognize that mailman can accept a fake sender . Example, I have a maillist with only an email account (xyz@abc.com) can send messages to all emails in the list. But , if someone can send a fake "From address" is xyz@abc.com, mailman will delivery messages to the list . This is a security problem. Can we prevent this from happening ?
Mailman is too far "downstream" to do this very effectively. It is possible to set up Mailman so that all posts will be moderated except those containing an "Approved: PASSWORD" header. This header is then stripped from the distributed version. However, such passwords can be leaked in various ways or sniffed from the mail in the transport between the sender and Mailman. It's not terribly secure.
A better way to do this would be to set up the MTA on Mailman's host to only deliver to the list address (ie, Mailman) if the sender has been authenticated (eg, with TLS).
On Oct 31, 2009, at 1:28 AM, Stephen J. Turnbull wrote:
A better way to do this would be to set up the MTA on Mailman's host to only deliver to the list address (ie, Mailman) if the sender has been authenticated (eg, with TLS).
Or to use digital signatures for sender verification. This is not
something that Mailman currently supports.
-Barry
Barry Warsaw wrote:
On Oct 31, 2009, at 1:28 AM, Stephen J. Turnbull wrote:
A better way to do this would be to set up the MTA on Mailman's host to only deliver to the list address (ie, Mailman) if the sender has been authenticated (eg, with TLS).
Or to use digital signatures for sender verification. This is not something that Mailman currently supports.
-Barry
I tried posting to the list several times now without success. I hope this this one finally gets through.
Another way to deal with this is sender confirmation by email, where, like subscriber confirmation by email, a message is sent with a confirmation link. Mailman doesn't have this capability presently but it seems to me that since it already has subscriber confirmation, it should be possible to adapt that sender confirmation.
This sender confirmation by email feature is available in L-Soft's LISTSERV, and it is an essential way to avoid fake email.
In a post a few years ago Barry said that this feature was going to be in vers. 2.2, but that version never materialized. Will it be in vers. 3?
Barry Warsaw wrote:
On Oct 31, 2009, at 1:28 AM, Stephen J. Turnbull wrote:
A better way to do this would be to set up the MTA on Mailman's host to only deliver to the list address (ie, Mailman) if the sender has been authenticated (eg, with TLS).
Or to use digital signatures for sender verification. This is not something that Mailman currently supports.
I don't know if the patches at http://non-gnu.uvt.nl/mailman-ssls/ would be helpful here or not. It's an attempt to add some OpenPGP and S/MIME capabilities to Mailman.
On Oct 31, 2009, at 10:54 AM, Todd Zullinger wrote:
I don't know if the patches at http://non-gnu.uvt.nl/mailman-ssls/ would be helpful here or not. It's an attempt to add some OpenPGP and S/MIME capabilities to Mailman.
I'll take a closer look at some point, but I suspect they won't be
relevant to Mailman 3. OTOH, I think it would be much easier to
implement in MM3.
-Barry
Hi Stephen, I can't do that because may be the sender is on another MTA and mailman server can't force they do an authentication. Is this a weak point of Mailman ? Best regards, Huu Hien
From: Stephen J. Turnbull [stephen@xemacs.org] Sent: Saturday, October 31, 2009 12:28 PM To: Hien HUYNH HUU Cc: mailman-users@python.org Subject: [Mailman-Users] Fake Email
Hien HUYNH HUU writes:
I recognize that mailman can accept a fake sender . Example, I have a maillist with only an email account (xyz@abc.com) can send messages to all emails in the list. But , if someone can send a fake "From address" is xyz@abc.com, mailman will delivery messages to the list . This is a security problem. Can we prevent this from happening ?
Mailman is too far "downstream" to do this very effectively. It is possible to set up Mailman so that all posts will be moderated except those containing an "Approved: PASSWORD" header. This header is then stripped from the distributed version. However, such passwords can be leaked in various ways or sniffed from the mail in the transport between the sender and Mailman. It's not terribly secure.
A better way to do this would be to set up the MTA on Mailman's host to only deliver to the list address (ie, Mailman) if the sender has been authenticated (eg, with TLS).
Hi,
HOw would you propose such verification of the authenticity of a sender be performed in Mailman?
It's hard enough to do anyway, but as has been pointed out, it's probably more the function of the MTA than of Mailman. The MTA can do things like insist on client-side certificates and other such measures which may or may not be helpful, and would have the advantage of screening out such Emails for everyone served by the mail server, not just the mailing lists.
Geoff.
Hien HUYNH HUU wrote:
Hi Stephen, I can't do that because may be the sender is on another MTA and mailman server can't force they do an authentication. Is this a weak point of Mailman ?
They still could connect and authenticate to the Mailman server's MTA for list posting purposes.
If for some reason they can't (e.g. their ISP redirects all port 25 connects to it's own MTA), you're back to Stephen's first remark - you can moderate everyone and post with an Approved: <password> header where <password> is the list admin or moderator password. Setting and using the moderator password is preferred to limit the damage in case it leaks.
Hien HUYNH HUU writes:
Hi Stephen, I can't do that because may be the sender is on another MTA and mailman server can't force they do an authentication. Is this a weak point of Mailman ?
No, this is a weak point of your MTA. The MTA has all the information needed, and in principle can force an authentication. Mailman only knows what the MTA tells it.
Specifically, the SMTP protocol goes:
HELO # the sender MTA identifies itself MAIL FROM # the sender MTA identifies the sender mailbox RCPT TO # the sender MTA identifies the recipients DATA # the sender MTA sends the message text including # header fields QUIT # the sender MTA hangs up, session over
Now, the receiver MTA prepends some so-called "trace header" fields, which usually contain the HELO, MAIL FROM, and RCPT TO information in some form, as well as timestamps and queue IDs. It may also transform the Content-Transfer-Encoding of the body (eg, from BASE64 to 8bit or vice versa). *Otherwise it hands Mailman exactly the same DATA that it got.* That DATA could be the truth, it could be a lie, it could be complete garbage. The MTA doesn't care, and Mailman has no way to check.
It's true, as Barry says, that you could use signed messages to authenticate, but this is not as good, for three reasons:
(1) Mailman as distributed doesn't implement this yet. (2) 3rd party patches are available but they have not been extensively tested. TLS facilities of MTAs are in widespread use and have been thoroughly tested. (3) Having Mailman do the authentication means accepting the mail at the MTA. This opens you up to the annoyance of spam and the danger of a denial-of-service attack (either on your bandwidth or on your disk space).
If you really want Mailman to do the authentication, you can either use the Approved header field, which is not very secure, or you can use the 3rd-party patch to use public-key signatures which somebody else mentioned. I'm pretty sure that should work OK because the theory is straightforward, but haven't reviewed it or used it myself, YMMV.
On Nov 1, 2009, at 9:06 PM, Stephen J. Turnbull wrote:
If you really want Mailman to do the authentication, you can either use the Approved header field, which is not very secure, or you can use the 3rd-party patch to use public-key signatures which somebody else mentioned. I'm pretty sure that should work OK because the theory is straightforward, but haven't reviewed it or used it myself,
In theory, it would also be possible for Mailman to trust
authentication information that the receiving MTA placed into the
headers. It's the same as having Mailman inspect spam headers that
some upstream-to-Mailman spam filter places into the message to
determine whether the message should reach the list membership.
-Barry
participants (7)
-
Barry Warsaw -
Conrad Richter -
Geoff Shang -
Hien HUYNH HUU -
Mark Sapiro -
Stephen J. Turnbull -
Todd Zullinger