[pmwiki-users] Mail Post Manual Trigger

Joachim Durchholz jo at durchholz.org
Sat Apr 30 04:06:49 CDT 2005


Neil Herber wrote:

> Joachim Durchholz is rumored to have said:
> 
>> Neil Herber wrote:
>>
>>> A login system that stored email addresses is probably the only 
>>> practical solution. Anything else gets very messy very fast.
>>> How does a "subscriber" figure out which pages they are subscribed
>>> to?
>>
>> This could be part of the mailpost info.
>> Or sent once a month (or something, probably a site-wide configuration).
> 
> Wouldn't this require writing to a script or configuration file? Or does 
> mailpost have a dedicated page that it gets email addresses from?

Mailpost addresses should be stored as page attributes.

Finding what pages a given user has subscribed to can become a bit 
tedious that way. It's probably easier to let PmWiki scan the entire 
site and collect that information for all users at a time.

(Note that reading the attributes of all pages is far less 
time-consuming than reading the entire page.)

>>> How do they cancel one or more or all subscriptions?
>>
>> That's analogous to subscription. No issue here.
> 
> Just trying to visualize the matrix/list/checkboxes/whatever ...

No matrix. If you wish to unsubscribe from a page, call that page up and 
click on the "unsubscribe" link (that should be there instead of the 
former "subscribe" link).

It would be nice if there were a "general unsubscribe" feature. I 
envision the "subscribe" and "unsubscribe" links leading to a page where 
people can do various things, like (un)subscribe to the current page, 
cancel subscriptions for a field in the farm, or cancel them for the 
entire site. To avoid having to scan the entire site and update all the 
mailpost attribute, PmWiki could store such unsubscription information 
in a separate file and filter these addresses, until it does its next 
round of general clean-up.

>>> How do they update their email address?
>>
>> Unsubscribe and resubscribe. (Not a pretty solution.)
> 
> Not too bad if email is only stored once per user, but if once per 
> watched page this is more than "not pretty".

I meant "not pretty for the user". PmWiki couldn't care less :-)

>>> What should the admin do when email starts bouncing?
>>
>> PmWiki should automatically stop sending mails.
> 
> That means PmWiki need to be able to watch a POP3 mailbox or something 
> similar. Does such a facility exist?

It needs that facility anyway, if only to verify that an email address 
exists and the human reading these mails approves getting PmWiki mails.

PHP comes with an IMAP library (wich can also read POP3). Version 
availability is good, the vast majority of functions are available since 
PHP 3.0.something; expect exceptions for quota and ACL handling.

>>> What does the admin do when the subscriber complains about being
>>> spammed?
>>
>> I.e. if mail goes to abuse at wiki.tld.
>>
>> For that case, there should be a list of mail addresses that cannot
>> subscribe. (If the user ever wants to get a subscription, he can send
>> another mail to the wiki admin.)
> 
> What this usually means is that the admin gets lumbered with the task of 
> removing all of the user's watch flags or email addresses. I not making 
> any presumptions here, but have you administered a regular mailing list? 
> The biggest problem I run into is people who subscribe with 
> Hotmail-style accounts that they forward to their real account. Then 
> when their real account dies, I get bounces from real at example.com, which 
> doesn't exist in the user database - because it was being forwarded from 
> fake at hotmail.example.com.

It's enough if there's a file of "don't ever send mails to these" addresses.

Initially, PmWiki can simply ignore bounces. In a later stage, PmWiki 
could analyse them and adjust subscriptions accordingly.

>>> These problems may not be big ones for private or limited audience 
>>> wikis, but a public wiki could have thousands of users all watching 
>>> different pages.
>>
>> Have a list of mail addresses on each page (e.g. as a page attribute).
> 
> This makes bounce/change-of-address processing a royal pain.

Only if it's manual. PmWiki can automate these tasks. It could be done 
in a primitive fashion initially, with better solutions as experience 
shows where they are really needed.

Address changes can be a real problem. One solution would be this:

1) Do mailposts only for people with a user account.
2) Pages don't have a list of mail addresses, they have a list of user 
accounts. When PmWiki sets up a page change mail, it goes through the 
listed user accounts and picks the mail addresses from there.

Advantages:
+ This also makes mail address verification easier. Without user 
accounts, PmWiki must do mail address validation for every page 
subscription, and that can become tedious for users. With user accounts, 
PmWiki can validate once when the mail address is used for the first time.

Disadvantages:
- There's an additional level of indirection, which means some 
additional PHP processing. I don't think this will become a factor until 
there are thousands of accounts subscribed to a page (in which case the 
site admin should have a better CPU anyway, I think...)
- It makes mailposts incompatible with old-style password-based page 
protection. I.e. you *must* have user accounts to do this kind of 
mailpost. I don't particularly like that because requiring registration 
for whatever feature creates a barrier, but it may be an acceptable 
disadvantage anyway.

Regards,
Jo



More information about the pmwiki-users mailing list