[
https://issues.apache.org/jira/browse/WHIMSY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064810#comment-15064810
]
Sam Ruby commented on WHIMSY-30:
--------------------------------
Current progress: https://github.com/apache/whimsy/tree/secmail/www/secmail
> Redo secmail
> ------------
>
> Key: WHIMSY-30
> URL: https://issues.apache.org/jira/browse/WHIMSY-30
> Project: Whimsy
> Issue Type: Bug
> Reporter: Sam Ruby
>
> Currently secmail is a toll that runs on minotaur, reads mbox files,
> implements a number of heuristics, and writes to svn (documents/received).
> Issues:
> * infrastructure plans are to retire minotaur
> * mbox files may be going away as a primary mechanism for storing mail
> * the heuristics implemented, while useful, may at times produce incorrect
> results -- ignoring some files and not handling others correctly.
> * writes to svn is occasionally problematic, which includes both transient
> problems (svn or LDAP down) and software problems (e.g., workbench leaving
> around empty directories)
> * overall, having the secmail as a separate process makes error recovery and
> debugging more difficult. A malformed email (typically spam) can wedge the
> process entirely.
> The proposal is to install a mail server on whimsy-vm (probably dovecot) and
> add whimsy-vm to the secretary mail alias. Then change the secretary
> workbench to parse email from the dovecot mbox files instead of the
> documents/received directory.
> Advantages:
> * decouples secmail from the infrastructure plans for changing how mail is
> processed
> * can reduce and/or eliminate heuristics. We can start from scratch (show
> all emails) and incrementally add rules which will hide emails that match a
> given pattern.
> * should svn be down, the user of the workbench will quickly be aware of that
> and will try again later; this is fundamentally more resilient than automated
> processes.
> * spam will never be put in svn. It also won't be able to wedge the tool.
> Badly formed emails can simply be deleted from the mbox file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
