00468: Posting to PmWIki Using Email
Description: Develop the code needed to be able to post to PmWiki using email as the input source.
Ideal actions from within the email would include:
- ability to target
- a particular group
- a particular page
- a place within a selected page
- create the destination page
- identification of the author
- setting the 'title' for a page
- embedding PmWiki markup
- at admin's option, embedding HTML markup
- markup that could be used to select only certain parts of the email
--- I use this feature with a blog and I love it. Not sure how I would use it with a wiki but maybe as a need for it.
WHR
Could be useful to get shy "naive" users to post information relevant for their group to the wiki "en passant", using a tools they already know - their mail program. --Henning July 05, 2006, at 10:07 AM
Could be also a way to circumvent maximum file sizes in file uploads. ;) --ThomasP July 14, 2006
We could use this as a way for users to report problems quickly. Vince Nov 10, 2006
Thought was a great for copying little snips from emails directly to a wiki archive. FAQ's, forwarded email stuff you like, etc. Also am thinking about using for a email capable forum-like application. And I've considered a sort of a personal email management system. The main reason I'd like this, actually, is because PmWiki can already do about everything I can think of but this. And I'm all for stretching it to its limits. The more it can do, the more options there are for creative fertile minds. Cheers, Caveman November 10, 2006, at 02:20 PM
Is there any idea how to implement it? Which interface(s) to use? Has anyone seen something similar in another Wiki, Blog, or whatever? Armin December 11, 2006, at 10:30 a.m. GMT
Got some basic indication how to do it: http://wiki.wordpress.org/?pagename=How%20To%20Blog%20By%20Email Armin December 11, 2006, at 10:44 a.m. GMT
Found an excellent PHP Class named pop3.php at http://www.phpclasses.org/browse/package/2.html , which is a perfect interface to any (?) POP3 mailbox. Tested it with an account on the same server (localhost) and at another server (www.something.com). I could poll all messages, specified messages, delete messages, read all lines, read specified lines, etc. etc.. - just powerful!
It would be easy to use it as a starting point for email-posts in PmWiki, but the problem is: How to proceed in detail?
- Build an interface
- Special mail-header with passwords? In the first line of the message?
- Append to which group.files? Specified in the next mail line?
- Where to append? At the end?
- How to separate postings?
- Create a special header for each posting? What does the header contain?
- Generate new files if gruop.file does not exist?
- How to handle HTML emails?
- Convert them into Wiki-Style?
- Delete HTML markup and accept only Wiki-Style
- Delete read and posted messages or keep them?
- Buffer time and header in an extra file to see if mails are already posted and to send a report like notify.php does?
- Optional "Mail arrived and is posted in group.file" email to sender?
- Polling done by cron jobs (not included at every host) or something simpler/different?
- How often check the mail?
I guess, that's only a fraction of possible questions. More questions and answers are welcome!
Armin December 11, 2006, at 06:05 a.m. GMT
Anyway, this could be a nice recipe --Dfaure
Trying to answer Armin's questions from the perspective of my intended application:
- Special mail-header with passwords? In the first line of the message?
- Not necessary.
- Append to which group.files? Specified in the next mail line?
- To make it easy for naive authors, all mails of one address can go into the same group
- (Maybe separation, where desired, can be achieved by assigning one recipient address per group?)
- How to separate postings?
- <hr> is fine
- Create a special header for each posting? What does the header contain?
- Mails already contain a lot of header information, so a special header would appear redundant
- How to handle HTML emails?
- Maybe as Attach:email.timestamp.html
- (This might be an option for all email types)
- Maybe as Attach:email.timestamp.html
- Delete read and posted messages or keep them?
- Delete
I don't know much about email formats, but it just occurred to me that the question how to handle file attachments has to be resolved, too. In my corporate/intranet environment, most of the emailed information is carried in attached files. --Henning January 17, 2007, at 12:27 PM
Here are a few of my thoughts on these questions. Would really like to see this!
- Special mail-header with passwords? In the first line of the message?
- Yes! or some other mechanism. At minimum, verify by allowed sender addresses. Preferably both.
- Append to which group.files? Specified in the next mail line?
- Perhaps use some notation in subject, like "This is the subject|Group.Name".
- If name not supplied use a default (SDV) group and timestamp.
- Should not be able to overwrite existing pages
- Should be able to limit posting to a limited array of groups, or any page.
- Where to append? At the end?
- One page per email.
- I don't need insertion capabilities. Can do pagelists with includes perhaps if needed.
- How to separate postings?
- See above.
- Create a special header for each posting? What does the header contain?
- See above.
- Generate new files if group.file does not exist?
- Yes, automatic page creation
- How to handle HTML emails? Convert them into Wiki-Style?
- Convert to Wiki better... if can be done well
- Delete HTML markup and accept only Wiki-Style ok.
- Attachments could be saved as attachments, perhaps linked at bottom of wiki page.
- Delete read and posted messages or keep them?
- Delete
- Buffer time and header in an extra file to see if mails are already posted and to send a report like notify.php does?
- Yes, this would be nice if could be notified.
- Optional "Mail arrived and is posted in group.file" email to sender?
- Yes, this is nice.
- Polling done by cron jobs (not included at every host) or something simpler/different?
- Cron works for me. I have a markup that can be triggered by manual viewing or cron. Could do same.
- How often check the mail?
- Configurable in config.php
- Delete read and posted messages or keep them?
- Delete
Agree with Henning that attachments are one of the most important things to process right. Would propose to save them in the upload folder, then use (:attachlist:) to display them.
BTW note, that much of the functionality desired will overlap with RSS feeds, so one can surely ride half the way with the existing horse.
To give my opinion to the questions:
- Special mail-header with passwords? In the first line of the message?
- In general yes, some form of authentication necessary; ip address would be enough for me. Wouldn't use the first line in the msg body, rather some unobstructive lines in form of
SentBy: ...,StoreAt: ...etc at the end. That's important obviously for "en passant" posting when users don't want to bother about format and recipients don't want to see control data as the first line of the mail. - Using the end has also another advantage: one can use just the usual signature of the mail client to control storage and even weakly authenticate the sender!!! Signatures in organizations are usually diverse enough to map one-to-one to persons.
- Instead of passwords, one can also consider using automated TANs generated for example by
md5($mykey . $universaltimeWithSecondsSetToZero). For authentication the server then checks the given TAN against corresponding self-generated TANs using the same key and, say, the last 30 minutes, i.e. 30 md5's, and lets pass if an equality was found. It would just need some small gadget on the client side, but does not expose passwords in clear text.
- In general yes, some form of authentication necessary; ip address would be enough for me. Wouldn't use the first line in the msg body, rather some unobstructive lines in form of
- Append to which group.files? Specified in the next mail line?
- As before, I wouldn't mess up the regular mail fields with this info, for acceptance reasons. Using different recipients addresses for target specifying is ok.
- Where to append? At the end?
- Maybe keep an option to not even append to wiki page, but keep in separate files instead and rather "compile" into wiki output wherever a
(:listmails:)markup is encountered (similarity to RSS feeds) - In other cases agree with: one page per mail, and pagelists and includefile markup for all :)
- Maybe keep an option to not even append to wiki page, but keep in separate files instead and rather "compile" into wiki output wherever a
- How to handle HTML emails? Convert them into Wiki-Style?
- Would not be central in my application, since human user writes mail. (Extracted content would be enough.)
- Delete read and posted messages or keep them?
- Configurable.
- Optional "Mail arrived and is posted in group.file" email to sender?
- Try use standard notification mechanism for this; possibly drill it up for it being capable of this.
- Polling done by cron jobs (not included at every host) or something simpler/different?
- Consider using an instantanous redirection to a php script upon reception of mail on an alias instead. (I have seen once the line
web0p1: |/home/scripts/process_mail.phpworking for postfix.) This is just faster and more systematic.
- Consider using an instantanous redirection to a php script upon reception of mail on an alias instead. (I have seen once the line
ThomasP March 27, 2007, at 02:04 AM
Hello,
for myself this is a very important feature of a wiki. Is there some progress or plan when to finish this plugin?
bjoern July 02, 2007, at 02:59 AM
I've put together a recipe that does nearly all of the above plus - you can find it at WikiBox. I would very much appreciate some feedback after testing. You can see a "live" example at this link
- --Peter Bowers August 25, 2008
I'm going ahead and closing this PITS entry on the strength of the existence of the WikiBox recipe. If some functionality is missing there you can either request it there on that recipe or else re-open this entry or start a new one. Peter Bowers March 04, 2009, at 06:39 AM
I reopened the feature request, as such a feature can be considered to be added to the core, or at least endorsed by Pm, the same way as there is now the PmForm recipe. --Petko March 04, 2009, at 08:04 AM
See also
- PITS.00028 (PmWiki as a blogging tool)
- Cookbook.PmFeed (... and other RSS feed tools)
- Cookbook.WikiBox
