![]() Is it okay to ask that Mailman be required for EBH to work? How much funds do people think I should ask for this? In particular, I'd like to get enough feedback to form an opinion on:Īre people willing to pay for this functionality? Suggestions, comments, criticisms, flames, are all welcome. While this might sound like fun to do, I don't think it'll be possible anytime soon, so let's not go there. I can integrate EBH with Mailman by spawning this script.Įlse I'd have to come up with some sort of python/php bridge (Mailman is written in python). Last time I looked, Mailman has a standalone command line script which can execute the bounce processing and output the results. To take this further, I'm also considering having Mailman as a dependency, and having EBH call into Mailman. (BTW, the email processing in the module Bounced Email is very simplistic, and I have doubts about it's robustness) Whenever Mailman updates it's bounce processing logic, I can just pick up the changes. It also means I don't have to reinvent the wheel (redoing text processing is something I very much want to avoid). Mailman has the most comprehensive bounce logic that I'm aware of, and it has special cases to handle bounce emails from Yahoo, Outlook etc. I'm seriously considering using the bounce email processing logic from Mailman. (Warning: this is potentially controversial) Thoughts on the actual text processing of bounced emails O EBH will first be developed for Drupal 5.x, with a 6.x version to follow. (Maybe we should even use the same module name?) O EBH can be a replacement for the current Bounced Email module. O EBH will require a working email server and an accessible mailbox, probably using IMAP(s) or POP(s). ![]() EBH periodically (via cron) open this mailbox and processes the emails within it. O Emails sent out by Drupal will have a return-path address set to a preconfigured mailbox. Of course, comments, suggestions, and opinions on the feature set are welcome. This is because I would prefer that EBH not store every single email sent out by the website. O Tag each bounced email with the original email which caused that bounce. O EBH will provide a way to list users with more than 3 bounced emails (so administrators can take the appropriate action) O Statistics are to be provided on bounced emails. So, for example, privileged users can view the bounce counts for simplenews subscribers which may not necessarily be user accounts. simplenews), EBH can display a list of the bounced emails associated with each email address. O For some modules which also store and use email addresses (ie. O EBH can also display individual bounce emails.ĮBH may optionally handle the following secondary use cases: O For each account, privileged users can view a count and a list of bounced emails associated with that account. O Privileged users can view a list of all bounced emails resulting from emails sent by the website. More on Bounced Email below.ĮBH will handle the following main use cases: The only thing that might have been relevant was Bounced Email, but that looks like a dead module. If I am incorrect in this observation, please let me know. See, for example, a previous post of mine which didn't elicit anything. I've been aware for the last year or so that Drupal core doesn't have any facilities to handle bounced emails. For convenience, let's call the proposed module EBH for now. The reverse bounty proposal is a module to handle bounced emails, and optionally to integrate statistics on bounced emails. ![]() ![]() Depending on the response, I may follow through, or postpone the idea. I'd like to post up some thoughts on an idea for a reverse bounty and gather some preliminary opinions from other people.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |