Justin Simoni wrote:
I think what you're looking for is something like:
http://www.faqs.org/rfcs/rfc1893.html
Or rfc3463. Thank you.
Just trying to use the right names for things.
RFC3463 are not even using the words bounce or block.
TRANSIENT
There seems to be a mixed interpretation of the term "persistent
transient failure". It seems to be used both for cases where a server is
still trying to deliver the message, and for cases when it has given up.
The correct way to decide which of the two it is, would be to see if
there also is a "delivery failure report".
That means that 5 is a bounce and 4 could be a bounce.
That means that the word transient should be avoided. We should use
"delayed" instead.
BLOCK
I found one place define a hard bounce as
A "hard" bounce is a message that's permanently undeliverable because
the address is invalid or because the recipient's mail server is
blocking your server.
But That doesn't mean that the email address doesn't exist. And the
blocking could be resolved. Should we really use the term "hard bounce"
for cases like this? I would rather say that the bounce is EITHER hard
OR block or soft.
I'm looking at:
Service Extension for DSNs (1891)
http://tools.ietf.org/html/rfc3461
The Multipart/Report Content Type (1892)
http://tools.ietf.org/html/rfc3462
Enhanced Mail System Status Codes (1893)
http://tools.ietf.org/html/rfc3463
An Extensible Message Format for DSNs (1894)
http://tools.ietf.org/html/rfc3464
Message Disposition Notification (2298)
http://tools.ietf.org/html/rfc3798
Automatic Responses to Electronic Mail
http://tools.ietf.org/html/rfc3834
My plan is to use standard responses, when available, and to handle
real-world cases, like MD::BounceParser.
The standard codes should be available, but the module should make it's
own interpretation of them, in order to correct for incompatible formats
used by different servers. That is what std_reason does.
The RFCs above gives some usable definitions. But we still need some
sort of hierarchy to sort in the emails.
I don't want to confuse the email containing a report, with the original
email referenced by the report. A property is_delivered or is_bounced
or is_delayed, should be used for the actual referenced messages. I'll
therefore names the properties is_dsn_delayd, for saying that this email
REPORTS on a delayed message. Not that it in itself is delayed.
Is there a better word for an email reporting on the status of another
email? It should be used both for rfc3461 DSNs, for rfc3798 MDNs and all
other standard and non-standard status-reports.
is_reply()
It should combine ordinary replies with is_auto_reply
is_auto_submitted()
Should basically try to guess if the email was written by a human or a
program. Will use rfc3834 if available
is_auto_reply()
if(is_reply AND is_auto_submitted)
is_dsn()
For any kind of delivery status notifications. Not just rfc3461. Always
a auto_reply.
is_dsn_bounce()
The referenced email will never reach the recipient. is_bounced should
be a property of the original email.
is_dsn_delayed()
The referenced email has not yet reached the recipient, but may still do
so. is_delayd should be a property of the original email. This is what
some call "transient".
is_dsn_bounce_hard()
No recipient with the given address exist.
is_dsn_bounce_block()
The referenced email could have been delivered but was not accepted.
is_dsn_bounce_block_server()
The referenced email was block based on one of the sending servers.
Sending the message again will probably not work, until the block has
been resolved.
is_dsn_bounce_block_message()
The message was bounced based on the properties of the email. Sending
another email to the same recipient may work.
is_dsn_bounce_soft()
Recipient exist, but message could not be delivered. Sending the
referenced email again, may work.
is_dsn_delivered()
These method-names above are just given for the sake of the discussion.
In the implementation, I will probably use the implementation I already
started. It could maybe look like:
if( $eml->is_dsn )
{
my $dsn = $eml->dsn;
if( $dsn->is_dsn_bounce )
{
my $bounce = $dsn->dsn_bounce;
if( $bounce->is_hard )
{
remove_from_my_list( $bounce->addresses );
}
}
}
In my experience, it's somewhat of a losing battle to attempt to
organize bounce messages so stringently
Let me at least try. ... But it doesn't have to be perfect.
For starters, I may want to just filter out non-human emails from a send
list:
$eml->remove if $eml->classified->is_auto_submitted;
Either way. I'm asking for how to use the terms involved.
The terms used should at least be consistent within the same module.
--
/ Jonas - http://paranormal.se/Jonas_Liljegren.html
