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_ball@merck.com (I regret the presence of the legal disclaimer but I have no control over it) ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==============================================================================
"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 -- richard_ball@merck.com (I regret the presence of the legal disclaimer but I have no control over it) ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==============================================================================
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 -- richard_ball@merck.com (I regret the presence of the legal disclaimer but I have no control over it) ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==============================================================================
participants (2)
-
Richard G. Ball -
Werner Reisberger