≡

wincent.dev

  • Products
  • Blog
  • Wiki
  • Issues
You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.
Home » Issues » Feature request #1134

Feature request #1134: Handle incoming mail

Kind feature request
Product wincent.dev
When Created 2008-09-11T15:16:33Z, updated 2009-02-20T18:53:05Z
Status open
Reporter Greg Hurrell
Tags no tags

Description

Cleaning out the "TODO" file found this:

HANDLE INCOMING MAIL TO (the support account)@example.com

these can all be classified as private support tickets by default
add incoming user email as an account
email password to the user
and a link to the issue
will need to include some kind of incoming email blacklist
and a way for users to notify of abuse
run as a cron job every minute (five minutes?)
is there mail in the queue?
if so, run a rake task to process the queue
that way we avoid overhead of bootstrapping rails unless there is really mail to process
and if there is, we do it all in one batch, so no DOS

Comments

  1. Greg Hurrell 2009-02-14T05:47:42Z

    Ok, I've started work on this now.

    Currently have a background worker daemon that wakes up every 15 seconds to see if there's any work to do; in this way we just bootstrap Rails once rather than every time we run.

    The first job of this worker daemon is going to be to check for handling incoming email, but I plan to use the same daemon to handle all background processing tasks (don't want multiple daemons due to the memory footprint).

  2. Greg Hurrell 2009-02-14T08:52:17Z

    TMail RDoc: http://tmail.rubyforge.org/rdoc/index.html

  3. Greg Hurrell 2009-02-14T09:28:10Z

    As one example of this can be done, see how Redmine does it.

  4. Greg Hurrell 2009-02-20T18:48:14Z

    See also feature request #439, specifically this comment:

    The system would need to be extremely customer-friendly, so that means that something as simple as sending an email to the support address should auto-open a ticket for them. The customer should be able to receive support via email, or via the web, and either way the entire history of the incident should be visible via the web interface.

    Spam means that no auto-generated email could be sent until I had confirmed that the original message sent was not spam. In a way, accepting queries via email is better than doing it via the web, because it requires someone to actually send a message (unlike a web form where someone could enter any address even if they don't control it).

  5. Greg Hurrell 2009-02-20T18:53:05Z

    I've been watching the support account for a few days now to see how much spam it's getting. About 100 messages so far; perhaps 20 or 30 per day.

    So before we go live with this, I think I need some nicer method for mass-deleting spam tickets. This is likely to produce a lot of them...

Add a comment

Comments are now closed for this issue.

  • contact
  • legal

Menu

  • Blog
  • Wiki
  • Issues
  • Snippets