>Some MLMs these days have one address per command, at least for the very
>common commands like zubscribe. Sending a message to that address results
>in the command being executed with the From: address as the victim. Should
>we do this with Majordomo?
>
>I have a vaguely bad feeling about it. It's not difficult to do at all; I
>can write a new mj_command interface to do it in just a few minutes. But
>then we have to decide which commands get their own separate aliases. What
>about sites that don't want to add a pile of additional aliases, or sites
>running 1.94? They then become 'incompatible'. And you end up issuing
>confirmation tokens for every spam that hits these addresses. (Unless
>you actually still run auto or open lists, in which case you have bogus
>addresses added to your lists.)
(is Chuq on this list - I'm sure he's uses this)
I think this is going to definately be desired by some sites but as you
pointed out it's got negatives as well as positives so other sites may well
not want it. It should be possible for it to be a site selectable option so
I see no real problems with the incompatibility issue. Indeed - I think
it's highly likely that someone else would put in it at some point and
offer it as a patch if it didn't get put in now (which argues for it being
put in now as it'll probably be done better).
I would imagine that the interest here is 99% only for getting on and off
lists so I'd probably argue to restrict things to that.
With respect to sending out too many confirmation tokens and too readily
getting unconfirmed addresses on the list - I think these are problems that
are ideally going to be addressed anyways. Your site can still get bombed
with the slightly harder to do normal zubscribe requests.
Forgive me if I've missed out on a feature already implemented/planned (I
recall this being discussed before) but what I think may be wanted is the
ability to freeze (/bounce for approval) certain MLM actions based on some
stateful info. I think this falls into two areas, (a) having the ability to
set a state such that a MLM action may be frozen under certain
circumstances (e.g. zubscribe requests to lists on a given domain) and (b)
the ability to set triggers for this state to change (e.g. to have any
address that mails more than 5 times to a list have further messages
frozen/bounced for approval). I guess the key problem with this is not
blowing away performance and working out what the states/actions are.
Of course this is sort of how a lot of the MLM actions (send a message
through to the list / allow a command) already work so there should be a
general means of supporting (and extending) the theme.
BTW - is there ever an attempt to check, if appropriate, email
deliverability before accepting commands/messages etc. - this is usually
best done in the MTA. If the overhead of a bounced/ignored confirm token is
high it might be worth considering a check before generating a token.
Manar
(wishing he was in the US so it would be a sensible time and wondering if
being this tired means he's making even less sense than usual.)
Follow-Ups:
References:
|
|
