>>>>> "MR" == Mark Rafn <dagon@halcyon.com> writes:
MR> Why not write it such that any command could have it's own address.
MR> Write mj_command to read it's command line as a format string, and
MR> treat the result as a command.
There's not much need; the basic action for everything that you'd ever want
to use this with is "command list address" where 'command' and 'list' are
provided in the alias and address is taken from the header. Well, I
suppose you might want an alias to get a file but that's easily taken care
of.
list-zubscribe: /path/to/mj_command -d domain -l list -c zubscribe
MR> Yes and no. All methods that worked on 1.94 still should work on 2.0.
MR> There are now just new options available in addition.
And a whole class of Majordomo lists that are not interoperable with other
Majordomo lists. Perhaps this isn't such a terribly bad thing, but it's
not at all clear to me that I should work on it now.
MR> True, but tokens are pretty cheap.
But list owner's time isn't. You don't get accidental subscribe-bombs to
the Majordomo address. But when any message at all triggers a token that
may (depending on configuration, of course) end up in the owner's mailbox,
well, that's damned annoying. And you can't just ignore it, because it
will stick around for token_lifetime days, with a nice reminder being
generated after token_remind days. (Then again I suppose any owner
bothered by this would just use another method, like confirming with the
victim first. I have the basics of a mechanism to automatically nuke
tokens when the confirmation bounces, so they don't stick around.)
MR> Parsing and generating errors for the spam sent to the majordomo
MR> address is probably a whole lot worse.
Assuming you get it. It's pretty easy to just completely ignore bounce
mail from Majordomo autoresponses.
- J<
References:
|
|
