[jira] [Closed] (WHIMSY-30) Redo secmail

["Sam Ruby (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WHIMSY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sam Ruby closed WHIMSY-30.
--------------------------
    Resolution: Fixed

This was completed several months ago

> Redo secmail
> ------------
>
>                 Key: WHIMSY-30
>                 URL: https://issues.apache.org/jira/browse/WHIMSY-30
>             Project: Whimsy
>          Issue Type: Bug
>          Components: SecMail
>            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.15#6346)