I'm not following this thread closely, but I thought I'd say something about
extended status codes. Part of the idea of extended status codes is that you
should be able to determine the likely source of the problem by looking at the
second facet of the status code. Or to put it another way, the second facet of
the status code is supposed to indicate _who_ probably needs to fix the problem
(e.g. the sender, the MSA, a relay, the delivery agent, etc.)
When mail is blocked because of information from a party that is not actually
involved in transmission (e.g. a blackhole list), it makes sense to have a
separate 2nd facet code for this, because (in some sense) it's the blackhole
list that has to fix the problem before similar messages can be delivered in
the future. But the list below mixes several different sources in the same
facet code.
Keith (not the author of 1893, but I did come up with the scheme for numbering
extended status codes)
On May 11, 2011, at 6:55 AM, Hector Santos wrote:
Hector Santos wrote:
Also, one other category (Alert Status) perhaps to consider per code to
provide insight on what codes are good candidate for internal reporting,
feedback to operators, red "alert status", etc, so when the receiver
detecting a reason for example x.8.11, it can provide a suggestion about the
severity of the detection:
Code: | X.8.11
Sample Text: | IDENTITY has been compromised
Alert Status:| HIGH, Operator should be notified
BTW, this particular code, should be recommended to be a 5.8.11. I don't
think we want to encourage a 4.8.11 for a detected compromised account. How
about others like this? Hell, most of them :)
This is my fast, off the top of my head, opinion of the 55x vs 45x separation:
+-----------------------------------------------------------------------+
| Reply | Extended| |
| Code | Code | Sample Response Text |
|-------+---------+-----------------------------------------------------|
| any | X.8.0 | Undefined Policy detail |
| 550 | 5.8.1 | Message refused by local policy |
| any | X.8.2 | Excessive volume |
| 550 | 5.8.3 | IP listed on RBL RBL-NAME |
| any | X.8.4 | Too many invalid recipients |
| 550 | 5.8.5 | Unacceptable content |
| 550 | 5.8.6 | Suspected phishing attempt |
| any | X.8.7 | IDENTITY is dynamically blocked due to complaints |
| 550 | 5.8.8 | IDENTITY is permanently blocked due to complaints |
| any | X.8.9 | Recipient not accepting messages from IDENTITY |
| any | X.8.10 | IDENTITY is a dynamic IP |
| 550 | 5.8.11 | IDENTITY has been compromised |
| any | X.8.12 | IDENTITY is an un-delegated IP |
| any | X.8.13 | Reverse DNS lookup for IDENTITY failed |
| any | X.8.14 | IDENTITY is temporarily blocked |
| 550 | 5.8.15 | IDENTITY is permanently blocked |
| any | X.8.16 | IDENTITY is an open relay |
| 550 | 5.8.17 | Malformed content |
| any | X.8.18 | Recipients have complained about included content |
| any | X.8.19 | IDENTITY temporarily rate limited due to complaints.|
| any | X.8.20 | IDENTITY temporarily rate limited |
| any | X.8.21 | IDENTITY-A is a non-authorized sender for IDENTITY-B|
| 550 | 5.8.22 | Message contains a virus |
| 550 | 5.8.23 | IDENTITY has been permanently deferred |
| 550 | 5.8.24 | messages from IDENTITY not accepted |
| any | X.8.25 | messages from local dynamic network not accepted |
| 450 | X.8.26 | INDENTITY Greylisted, please retry later |
+-----------------------------------------------------------------------+
Any code description that says "permanent," according to SMTP should be 55x
and the main idea behind permanent is to tell the client not the same
transaction again which will repeat the same result. IOW, something has to
change on the client side. Temporary means that something may change (i.e.
policy, limits) on the receiver side for repeated attempts of the same
transaction.
--
Sincerely
Hector Santos
http://www.santronics.com