>>>>> "MH" == Manar Hussain <manar@ivision.co.uk> writes:
MH> I think this is going to definately be desired by some sites but as you
MH> pointed out it's got negatives as well as positives so other sites may well
MH> not want it.
But then you lose uniformity between sites. I see this as a rather bad
thing.
MH> Forgive me if I've missed out on a feature already implemented/planned (I
MH> recall this being discussed before) but what I think may be wanted is the
MH> ability to freeze (/bounce for approval) certain MLM actions based on some
MH> stateful info.
This has been discussed. Of course there is a way to limit any action
based on regexp match on the victim address, membership in any of an
arbitrary number of address lists and action specific variable comparisons,
but nobody has yet come up with a well thought out concept for time-based
limiting. When that is done, the access control mechanism already supports
it.
There have been various mechanisms proposed but it is desirable to have
one that requires no per-user state and which doesn't require keeping a
large amount of global state. This isn't necessarily an easy thing to do.
MH> BTW - is there ever an attempt to check, if appropriate, email
MH> deliverability before accepting commands/messages etc.
This is, of course, completely impossible. Even for an MTA. The only way
to ensure deliverability is to send a message and request a response. Of
course we check for syntactic validity of the address, but that is a
completely different thing.
MH> If the overhead of a bounced/ignored confirm token is high it might be
MH> worth considering a check before generating a token.
The reason you send tokens is to ensure deliverability. Well, that and to
actually ensure that the victim wants the action to be taken, but I
consider that a fortunate coincidence.
- J<
Follow-Ups:
References:
|
|
