Confirmation Messages and Modified Subject Lines
Hello all. I recently discovered a concern with the manner in which Mailman handles confirmation messages with modified subject lines.
Normally a confirmation message has a subject line such as: confirm xxx...
It is understood that the subject line is not to be modified. With all confirmation subscription messages there is a note sent stating as such. Most recipients have no problem with this, but occasionally before a confirmation message reaches its final destination, a spam filter, virus scanner, mail server, etc will modify the subject line so it arrives modified in the end users' mailbox. For example, a tag like "[BULK]" is added: "[BULK] confirm xxx...". Now the end user follows the directions and does not modify the message BUT it's already modified.
This extra text in the subject line causes problems (e.g. replies to confirmations are not successfully processed so an user end does not become a member of the list as he/she would expect). However replying to a confirmation message with a prefix like "Re:" does not seem to create problems, for example: Re: confirm xxx...
Would it not be better to have Mailman search for a substring, "confirm xxx..."? This would allow any prefixes to be ignored.
If this seems like a reasonable change, which component of Mailman is responsible for this? (still learning how Mailman operates).
-Adrian
Adrian Wells wrote:
Hello all. I recently discovered a concern with the manner in which Mailman handles confirmation messages with modified subject lines.
Normally a confirmation message has a subject line such as: confirm xxx...
It is understood that the subject line is not to be modified. With all confirmation subscription messages there is a note sent stating as such. Most recipients have no problem with this, but occasionally before a confirmation message reaches its final destination, a spam filter, virus scanner, mail server, etc will modify the subject line so it arrives modified in the end users' mailbox. For example, a tag like "[BULK]" is added: "[BULK] confirm xxx...". Now the end user follows the directions and does not modify the message BUT it's already modified.
This extra text in the subject line causes problems (e.g. replies to confirmations are not successfully processed so an user end does not become a member of the list as he/she would expect). However replying to a confirmation message with a prefix like "Re:" does not seem to create problems, for example: Re: confirm xxx...
Actually, a single extra field such as "[BULK] confirm token_string" should work OK, but "Re: [BULK] confirm token_string" will not work. This is because if the subject itself is not a valid command, the first 'argument' of the subject is removed and the remainder is tried again, but this is only done once.
I once worked up a patch to do it up to twice to handle "Re : confirm token_string" which you might be able to find in the archives of mailman-users@python.org or maybe this list.
Would it not be better to have Mailman search for a substring, "confirm xxx..."? This would allow any prefixes to be ignored.
If this seems like a reasonable change, which component of Mailman is responsible for this? (still learning how Mailman operates).
The code is in the do_command() method in Mailman/Queue/CommandRunner.py
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
At 3:16 PM -0800 2005-12-06, Mark Sapiro wrote:
I once worked up a patch to do it up to twice to handle "Re : confirm token_string" which you might be able to find in the archives of mailman-users@python.org or maybe this list.
This should be taken to the logical conclusion. Keep popping off prefixes until something useful can be found, or you run out of data. You should probably also strip out all punctuation, too. Heck, strip out all non-alphanumeric data.
The code is in the do_command() method in Mailman/Queue/CommandRunner.py
If I can get some time to look at this within the next few months, I hope to be able to fix this.
Thanks!-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See <http://www.lopsa.org/>.
Brad Knowles wrote:
This should be taken to the logical conclusion. Keep popping off prefixes until something useful can be found, or you run out of data. You should probably also strip out all punctuation, too. Heck, strip out all non-alphanumeric data.
I think Brad is on the right track here, but we can't strip out all non alphanumeric characters because this is common code for all commands sent to the list-request address and valid commands can contain '=', passwords and email addresses.
I think the correct approach is to keep popping arguments until you hit a valid command or run out of arguments, but there is an issue here as well, although I think it is already an issue anyway. Here it is.
Suppose I send an email to list-request@example.com that has
Subject: I want to subscribe to the list
and body line
subscribe a_paswd nodigest
This is a valid subscription email, but if we strip arguments off the subject until we hit a valid command word, we'll try to process the command "subscribe to the list" which will fail and the failure will cause the valid command in the body to be skipped. Of course, the same issue currently exists if the valid command is sent in the body with
Subject: subscribe to the list
but at least here, it is the users 'fault'.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
At 9:12 PM -0800 2005-12-06, Mark Sapiro wrote:
This is a valid subscription email, but if we strip arguments off the subject until we hit a valid command word, we'll try to process the command "subscribe to the list" which will fail and the failure will cause the valid command in the body to be skipped.
The easy way to handle that is to go ahead and try to process the body of a message, regardless of the success or failure of the ability to process the subject line.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755LOPSA member since December 2005. See <http://www.lopsa.org/>.
Brad Knowles wrote:
The easy way to handle that is to go ahead and try to process the body of a message, regardless of the success or failure of the ability to process the subject line.
You have to be careful about that, or you may reopen a 2.1.4 hole allowing retrieval of another members password.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Adrian Wells -
Brad Knowles -
Mark Sapiro