Ricardo SIGNES wrote:

"Hard" and "soft" are definitely well-established terms for
describing bounces. I think that "transient bounce" is a weird
choice, though.  It's not a bounce, and if it was, a transient bounce
would sound, to me, like a soft bounce.  It's just a DSN that isn't a
bounce reporting DSN.

How about trying to define some terms?

If there is a good summary on the web, please give me a pointer.

These are my guesses about how the terms could be defined...

reply:
The email was sent in response to another message

auto-reply:
A reply generated automaticly by a program. May in some instances be sent upon human intervention.

transient:
The email has not yet reached the recipient

bounce:
The email will never reach the recipient

hard bounce:
No recipient with the given address exist

soft bounce:
Recipient exist, but message could not be delivered

delivered:
The email has reached the recipient

vacation:
The email has reached the recipient? But will not be read until a certain time

challenge response:
A transient status, needing an action from your part

address changed:
May or may not also be a bounce

message changed:
The message was forwarded, but with some changes, such as attachement removal

block:
Message could have been delivered but was not accepted

message block:
The message was bounced based on the properties of the email

server block:
The message was block based on one of the sending servers



That would give the tree: (Using # * + - for indicating levels, in case of bad email reformatting. ;-)

reply
 # auto-reply
   * bounce
     + hard
       - address changed
     + soft
     + block
       - message
       - server
   * transient
     + challenge response
     + message changed
   * delivered
     + vacation
     + address changed
     + message changed



And some common informational bits given in relation to one or more of the above would involve: spam, virus, message size, server errors and mailbox full.


A lot of these are interconnected. I'm not sure how to split it up in a good way. One module may want to check the response from another module.

But std_reason should be expanded to give room for more information.




http://jonas.liljegren.org/perl/dist/Email-Classifier-0.01.tar.gz

--
/ Jonas  -  http://jonas.liljegren.org/myself/

Reply via email to