Re: [Mantisbt-dev] handling incoming mail

[Glen S. <grs...@co...>]

Mitch (WebCob) wrote:

>>I'd like to consider an additional use case where not everyone that
>>might submit interesting information via mail has access to the web
>>interface. Plus - you'd better not bounce incoming mail from customers
>>who pay for the support service :-)
>>    
>>
>
>Ok, but regardless, if someone was to send an email to mailman (for example)
>the config can say "if you can't identify a command, send the user an error"
>vs. "if you can't identify a command, accept the message and allow a human
>admin to sort out the mess later".
>
>As to the comment about not bouncing mail from customers, I don't understand
>why not... we do this from our mailing list managers... the system works a
>certain way and has rules. The rules are documented. If someone doesn't
>follow the rules, they get an error message. To do otherwise would result in
>chaos - no one would ever bother to read the rules, and service request turn
>around times would suffer.
>  
>
I totally agree with this statement.  In the typical use case:  A "case 
number" is assigned, and that case number must remain in the subject in 
order to allow the message to be processed, people are used to that.  
It's OK fine to allow that.  Then include the enture body as a bugnote 
on that bug if there's no way of parsing out the intended comments 
specific to that message.

>I would expect that any larger user would require the option of being able
>to bounce (or send error messages) to any client who submits incomplete
>information - whatever that info may be...
>
>For example, when responding to a bug, the project and bug id must be
>present, and active. Otherwise, they get an error (unless you choose to keep
>a work queue for the human admin).
>
>If you submit a new bug, it must include the project (otherwise which human
>admin should review it?)
>
>All of these should be optional of course, but need to be there to eliminate
>the possibility of backlog... it's easier for the user to resent after
>adding their project name than it is to wait a day or so for a human admin
>to correct a spelling mistake and reprocess - eh?
>  
>
If you're talking about an option for manual mail sort -- which I am 
less in support of than the overall concept of allowing someone to 
respond to a bug status email (which seems to be the context in which 
we're mostly talking), then you should include a "default server 
mailbox" for the server admin to decide which project it belongs to.  Of 
course, if this manual routing feature is included then I would 
certainly want a way to reject them outright automatically!

Regards,

-- 
Glen Starrett