While my first message on this issue waits for approval from the mailing list admin (don't know why) I send a second solution for the bug with addresses like foo@is.not.so.com or alex@wait.change.ti. Such addresses cannot be subscribed because the following line in rc.request matches if the subject line contains "subscribe alex@wait.change.ti".
* -100^0 ^Subject:(.*[^a-z])?(Re:|erro|change|problem|((can)?not|.*n't)>)
I would suggest to modify the third condition line of the recipe
* 100^0 ^Subject:[ ]*archive
to
* 100^0 ^Subject:[ ]*(archive|(un)?subscribe)
My first solution (which could be come late if the list admin is on holidays) suggested to modify the first regex in brackets of the first condition line, removing the .* greedy regex, but this would weaken the filtering capabilities for non administrative messages.
Werner
On [2003-Apr-15] Werner Reisberger werner@pure.ch wrote:
While my first message on this issue waits for approval from the mailing list admin (don't know why) I send a second solution for the bug with addresses like foo@is.not.so.com or alex@wait.change.ti. Such addresses cannot be subscribed because the following line in rc.request matches if the subject line contains "subscribe alex@wait.change.ti".
Perhaps your first message explained the problem more fully but from what I can gather you want to accept subject lines like "subscribe <some address>" rather than ignoring them. Correct? You could simply pre-process these messages to remove any email address since it isn't being used anyway.
Rich
"Richard G. Ball" Richard_Ball@merck.com wrote:
While my first message on this issue waits for approval from the mailing
list
admin (don't know why) I send a second solution for the bug with
addresses
like foo@is.not.so.com or alex@wait.change.ti. Such addresses cannot be subscribed because the following line in rc.request matches if the
subject
line contains "subscribe alex@wait.change.ti".
Perhaps your first message explained the problem more fully but from what I can gather you want to accept subject lines like "subscribe <some address>" rather than ignoring them. Correct?
Yes. Some (but not all) will be ignored, falsely assuming they are not administrative messages (e. g. foo@change.com or foo@not.so.com).
You could simply pre-process these messages to remove any email address since it isn't being used anyway.
Why isn't it used anymore? It has been always very useful to (un)subscribe from an address which isn't the address from where you are sending the request. I didn't saw any notice that this feature has been removed and I don't know why it should be necessary to remove it. Can you shed some light on this?
I think it's much easier to make the small modification in rc.request making the useful feature work flawlessly than to add extra recipe(s).
Anyway, if it will not be fixed in the official SmartList distribution I will fix it in the rc.request for the confirm addon because confirm depends on the "subscribe some address" feature.
Werner
On [2003-Apr-15] Werner Reisberger werner@pure.ch wrote:
You could simply pre-process these messages to remove any email address since it isn't being used anyway.
Why isn't it used anymore? It has been always very useful to (un)subscribe from an address which isn't the address from where you are sending the request. I didn't saw any notice that this feature has been removed and I don't know why it should be necessary to remove it. Can you shed some light on this?
No released version of SmartList I have ever used has actually accepted this form of (un)subscribe. For simple security the subscribe command would accept only the address from which the mail was sent (so a malicious user couldn't subscribe someone else nor could they unsubscribe someone else).
I think it's much easier to make the small modification in rc.request making the useful feature work flawlessly than to add extra recipe(s).
Anyway, if it will not be fixed in the official SmartList distribution I will fix it in the rc.request for the confirm addon because confirm depends on the "subscribe some address" feature.
I can understand that if you have the extra security of a well constructed confirm package then the ability to (un)subscribe an arbitrary address may have some advantages but the very few times such a circumstance has arisen on my lists it has been simple enough to handle it manually by the list admin.
Rich
Zitat von "Richard G. Ball" Richard_Ball@merck.com:
You could simply pre-process these messages to remove any email address since it isn't being used anyway.
Why isn't it used anymore? It has been always very useful to
(un)subscribe
from an address which isn't the address from where you are sending the
request.
I didn't saw any notice that this feature has been removed and I don't know why it should be necessary to remove it. Can you shed some light on
this?
No released version of SmartList I have ever used has actually accepted this form of (un)subscribe. For simple security the subscribe command would accept only the address from which the mail was sent (so a malicious user couldn't subscribe someone else nor could they unsubscribe someone else).
Security never had top priority with SmartList (which is used to manage rather unsecure messages). It was always possible to unsubscribe another address not mentioned in the "From(:)" header. Even the unsubscribe script from SmartList gives the advice to sent a new unsub request with the string
"unsubscribe the_address_you_meant"
if no email address in the request matches the addresses in the dist file.
Werner
Quoting "Richard G. Ball" Richard_Ball@merck.com: ...
You could simply pre-process these messages to remove any email address since it isn't being used anyway.
Just took a look into the subscribe script of SmartList v. 3.15 and saw that the script is searching for a "subscribe any_address" pattern in the subject line. If an address is found in this pattern space the address takes precedence over addresses in other parts of the message. It's therefore not true that this syntax isn't used anymore.
Werner
On [2003-Apr-15] Werner Reisberger werner@pure.ch wrote:
takes precedence over addresses in other parts of the message. It's therefore not true that this syntax isn't used anymore.
I stand corrected Werner.
Rich
smartlist@lists.rwth-aachen.de
-
Richard G. Ball -
Werner Reisberger