On Feb 18, 2008, at 6:47 PM, Jonas Liljegren wrote:
Ricardo SIGNES wrote:
"Hard" and "soft" are definitely well-established terms for
describing bounces.
How about trying to define some terms?
I think what you're looking for is something like:
http://www.faqs.org/rfcs/rfc1893.html
In my experience, it's somewhat of a losing battle to attempt to
organize bounce messages so stringently, since it seems that many
systems use many (sometimes, completely different) ways of bouncing
out a message and the status and reports they give you may be in an
attempt to spoof whatever it is that is to handle them.
I've had tons of, "fun" doing just that ;) And my systems basically
ignore things it doesn't understand and then figures out if a message
is a, "hard" or, "soft" bounce.
--
Justin Simoni
http://justinsimoni.com :: Art Portfolio
http://skazat.com :: Sketchbook
On Feb 18, 2008, at 6:47 PM, Jonas Liljegren wrote:
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://paranormal.se/Jonas_Liljegren.html
