On 3/12/2011 10:51 AM, [email protected] wrote:
Barbara Duprey wrote:
On 3/11/2011 12:52 PM, openoffice.mbourne<at>spamgourmet.com wrote:
Barbara Duprey wrote:
Another question is whether there is still a way to use a different
account for actions using an indirect form, like the old
[email protected]. If so, what is the
syntax? As you know, that was very handy to avoid problems with "munged"
addresses and so on.
There is for unsubscribe... From Sympa's help (once it realised I'm
not a spammer):
> All commands must be sent to the electronic address
> [email protected]
>
> You can put multiple commands in a message. These commands must
> appear in the message body and each line must contain only one
> command.
>
> Available commands are:
...
> SUBscribe <list> <name> * To subscribe or to confirm a
> subscription to <list>.
>
> UNSubscribe <list> <EMAIL> * To quit <list>. <EMAIL> is an optional
> email address, useful if different from your "From:" address.
> UNSubscribe * <EMAIL> * To quit all lists.
I'm not sure what the <name> parameter for SUBscribe is, but the
others are obvious. It doesn't look like you can subscribe a different
account (unless that's what <name> does?) although you can:
> INVITE <list> <email> * Invite <email> for subscription in
> <list>
so perhaps that allows you to initiate a subscribe for another address.
Mark.
Thanks, Mark! Since they use <EMAIL> or <email> rather than <name> for
the ones that clearly allow e-mail accounts to be specified, it seems
likely that <name> is only intended to specify the displayed name when
the user posts to a list, though it may be restricted to not contain
blanks, etc. (depending on the parser rules).
That would be my guess, too, although displayed name is usually included in the from: header each
time an email is sent.
I guess they were allowing for people to choose a different displayed name from the one they used
for the account. Not sure how useful that would be, but -- when in doubt, make something an option,
right?
It also looks as if you
can probably use either the fully spelled out command or the initial
letters, but it isn't clear whether case is relevant.
Case doesn't seem to matter - or at least it worked when I've sent the "help" and "lists" commands
entirely in lower case.
Thanks for checking, that's good.
One of the
problems people had with the OOo lists was that sometimes the
subscription was recorded with a "munged" address due to their
configuration, and then could not be canceled without replicating that
-- generally requiring use of the Return-Path header to dig it out. May
still be true here, unless the subscription process standardizes the
form of the address. That's the reason that I always recommended using
the indirect form in the subscribe.
UNSubscribe <list> <EMAIL> appears to be the way to unsubscribe in that situation (probably
doesn't even need the address to be mangled, since it's now in the body of the email rather than
encoded into the to: address).
The problem there came from the munging of the From address at subscribe time -- once the recorded
subscriber address was known, the unsubscribe worked when it specified the munged subscription
address using the indirect unsubscribe (here, the command you quote would be the analog), but
finding the recorded subscribed address was the issue. The Return-Path header had it, though.
Maybe the INVITE will allow that?
Attempting to invite another of my own addresses as a test...
Mark Bourne wrote:
invite users [address removed]
SYMPA wrote:
Command has been rejected :
invite users [address removed]
The 'invite' feature is unavailable.
So we appear to be out of luck subscribing an address other than the one in the from: header. Most
mail clients allow the from: address to be set, but some ISPs seem to block outgoing mail sent
from any address not in their own domain, and others have their outgoing mail server change the
from: header to the address registered with them overriding whatever is specified in the mail
client (I've found gmail's authenticated SMTP server does that).
Others change the From, too, sometimes because of anti-spamming protocols -- that's the "munging" i
referred to. I don't have any way to test this, but it would be good to know whether Sympa somehow
standardizes the subscription address from the From header when necessary. Otherwise, we'll have the
same problem here. But Return-Path is not helpful, it just shows <list>[email protected], so I
don't know how the subscribed address could be determined except by the owner or moderator doing
detective work on the subscription list. Paul got pretty good at that! Or maybe some script could
generate a Subscriber: header as the message is sent?
Barbara Duprey wrote:
Anyway, I'll see if I can get the whole help message for future reference.
--
------------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected] with Subject: help
