Disposition/notifications

[Chris Trudeau]

My previous post about things to think about in Julian's redesign got me to
thinking...about modular disposition/notifications.

Here's the question:

Does it make sense to adapt a more standard notification handling scheme?

If generally speaking you applied the same rule processing to
SPAM/filename/Virus, you could process notifications the same way...here is
what I'm thinking...flames welcome by the way:  (Obviously, these would
default to the approrpiate choice indicated by "*")

1.  Process the message for viruses
    A.  Infected
        1.  Cleaned
            a.  Disposition
*              1.  Deliver-deliver to user
                2.  Delete-drop the message on the floor
                3.  Store-quarantine the message to a defined location
                4.  Bounce-bounce the message back to the sender
                5.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                6.  Striphtml-strip the html from the message
                7.  Attachment-Convert the message/attachment to an
attachment
            b.  Notifications
                1.  To administrator (predefined and configurable report)
*              2.  To end user (configurable report)
        2.  Not Cleaned
            a.  Disposition
                1.  Deliver-deliver to user
                2.  Delete-drop the message on the floor
*              3.  Store-quarantine the message to a defined location
                4.  Bounce-bounce the message back to the sender
                5.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                6.  Striphtml-strip the html from the message
                7.  Attachment-Convert the message/attachment to an
attachment
            b.  Notifications
*              1.  To administrator (predefined and configurable report)
*              2.  To end user (configurable report)
     B.  Not infected
            1.  Disposition
*              a.  Deliver-deliver to user
                b.  Delete-drop the message on the floor
                c.  Store-quarantine the message to a defined location
                d.  Bounce-bounce the message back to the sender
                e.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                f.  Striphtml-strip the html from the message
                g.  Attachment-Convert the message/attachment to an
attachment
            2.  Notifications
                a.  To administrator (predefined and configurable report)
                b.  To end user (configurable report)

2.  SPAM processing

    A.  Not SPAM
            1.  Disposition
*              a.  Deliver-deliver to user
                b.  Delete-drop the message on the floor
                c.  Store-quarantine the message to a defined location
                d.  Bounce-bounce the message back to the sender
                e.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                f.  Striphtml-strip the html from the message
                g.  Attachment-Convert the message/attachment to an
attachment
            2.  Notifications
                a.  To administrator (predefined and configurable report)
                b.  To end user (configurable report)
    B. HIGH SPAM
            1.  Disposition
                a.  Deliver-deliver to user
*              b.  Delete-drop the message on the floor
                c.  Store-quarantine the message to a defined location
                d.  Bounce-bounce the message back to the sender
                e.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                f.  Striphtml-strip the html from the message
                g.  Attachment-Convert the message/attachment to an
attachment
            2.  Notifications
                a.  To administrator (predefined and configurable report)
                b.  To end user (configurable report)
    C.  SPAM
            1.  Disposition
                a.  Deliver-deliver to user
                b.  Delete-drop the message on the floor
*              c.  Store-quarantine the message to a defined location
                d.  Bounce-bounce the message back to the sender
                e.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                f.  Striphtml-strip the html from the message
                g.  Attachment-Convert the message/attachment to an
attachment
            2.  Notifications
*              a.  To administrator (predefined and configurable report)
                b.  To end user (configurable report)

3.  Filename/type rules

    A.  Allowed filename/type
            1.  Disposition
*              a.  Deliver-deliver to user
                b.  Delete-drop the message on the floor
                c.  Store-quarantine the message to a defined location
                d.  Bounce-bounce the message back to the sender
                e.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                f.  Striphtml-strip the html from the message
                g.  Attachment-Convert the message/attachment to an
attachment
            2.  Notifications
                a.  To administrator (predefined and configurable report)
                b.  To end user (configurable report)

       B.  Dis-allowed filename/type
            1.  Disposition
                a.  Deliver-deliver to user
                b.  Delete-drop the message on the floor
*              c.  Store-quarantine the message to a defined location
                d.  Bounce-bounce the message back to the sender
                e.  Forward-forward the message and attachment to a
dedicated box(es) for handling
                f.  Striphtml-strip the html from the message
                g.  Attachment-Convert the message/attachment to an
attachment
            2.  Notifications
*              a.  To administrator (predefined and configurable report)
*              b.  To end user (configurable report)


SUMMARY:  This "could" allow a modular design that would allow other
"handling" routines be stubbed into the overall framework.  Seems that the
code for disposition/notifications could be written once and referenced.
Each section could have a distinct "close" allowing rule processing to cease
allowing potentially better performance.  And end user and admin
notifications would be uniform and confirable across the board using
existing rules-based configuration...just a thought...

CT