Jeff Macdonald wrote:
Hi Folks,
There is a slight update, where I added a code for greylisting. I've
also updated the contact information to reflect my current job.
Draft can be found here:
https://datatracker.ietf.org/doc/draft-macdonald-antispam-registry/
...
If you've implemented this draft, please let me know.
Jeff,
We started a major upgrade of our MTA and your previous I-D revs were
already added part of the updated extended reply code text tables.
I'll updated to rev2.
First some quick review typos found:
X.8.4, typo "to" change to "too"
X.8.26, typo "INDENTIY" change to "IDENTITY"
A few suggestions.
1 - Motivations for supporting this proposed standard.
With this rev2 update with greylisting info, you might want to add
some motivations text to the introduction, for example after the 1st para:
Extended reply codes, such as X.8.26, can help improve
email communications under greylisted environments by
using smarter reschedule retransmissions.
For example, our retry table has a retry rule specifically for
Greylisting pushing up the few few retries, for example:
if reply.attempts < 3 then
if reply.code is 451 or
reply.text has "4.7.1" or
reply.text has "grey"
then
Reply.RetryMintutes(5)
2 - What is IDENTITY?
When we added the X.8.YYY entries, the immediate "scratch head" which
was what macros (for the SMTP session process entities) to use for the
IDENTITY in certain of the entries. It was not hard to figure out, but
it might help to add a terminology/definition section to describe what
IDENTITY is or might be.
2. Terminology and Definitions
2.1 IDENTITY
The IDENTITY can be any value reflected within the extended
reply code reason and response. It may be directly related
to the value being monitored or evaluated for anti-spam
purposes [in each stage of the SMTP state machine]. Generally,
the value is the SMTP client IP address or domain input from
the client, such as the return path provided in MAIL FROM: state.
Each extended reply code in section 4.1 provide further explicit
insights to the identity values are being considered.
Or whatever you think is better as a general definition:)
3 - Suggestion to add Summary table
I think a summary section with easy to read table (i.e. in "one" page
view) would greatly help readers simply pursuing the doc. It will
"sell" the proposal and increase consideration to implement. I would
add it before the IANA Consideration section but also consider
re-outlining the TOC and it as an introduction summary
1. Introduction
1.1 Introducing the Anti-Spam Subject
1.2 Summary of Enumerated Status Codes
2. Terminology and Definitions
3. Methodology of determining new detail codes
4. IANA Considerations
4.1. Enumerated Status Codes
1.2 Summary of Enumerated Status Codes
The following table summarizes when extended codes are applicable for
reply codes with example response text associated with the
extended code.
Please review the terminology section 2.1 for IDENTITY and the
section 4.1
IANA considerations to get detail information for each extended
reply code.
Table 1.0 - Anti-spam Extended Codes.
+-----------------------------------------------------------------------+
| Reply | Extended|
|
| Code | Code | Sample Response Text
|
|-------+---------+-----------------------------------------------------|
| any | X.8.0 | Undefined Policy detail
|
| any | X.8.1 | Message refused by local policy
|
| any | X.8.2 | Excessive volume
|
| any | X.8.3 | IP listed on RBL RBL-NAME
|
| any | X.8.4 | Too many invalid recipients
|
| any | X.8.5 | Unacceptable content
|
| any | X.8.6 | Suspected phishing attempt
|
| any | X.8.7 | IDENTITY is dynamically blocked due to
complaints |
| any | X.8.8 | IDENTITY is permanently blocked due to
complaints |
| any | X.8.9 | Recipient not accepting messages from IDENTIDY
|
| any | X.8.10 | IDENTITY is a dynamic IP
|
| any | X.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
|
| any | X.8.15 | IDENTITY is permanently blocked
|
| any | X.8.16 | IDENTITY is an open relay
|
| any | X.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|
| any | X.8.22 | Message contains a virus
|
| any | X.8.23 | IDENTITY has been permanently deferred
|
| any | X.8.24 | messages from IDENTITY not accepted
|
| any | X.8.25 | messages from local dynamic network not
accepted |
| 45z | X.8.26 | IDENTITY Greylisted, please retry later
|
+-----------------------------------------------------------------------+
Why use 45z for X.8.26?
For x.8.26, I was going to suggest changing that to 451, but its
probably better to use 45z with some informative notes for using
either 450 or 451. But having an explicit 450 somewhat tells SMTP
receivers to use 450 - period, and that may now what they wish to use.
The reason why is that there are already receivers using 451. Most, if
not all, early greylisting adopters began using the "Official"
GreyListing specs by the purported inventor:
http://projects.puremagic.com/greylisting/whitepaper.html
This doc was often referenced in the support mailing list and its
example for a response is:
451 4.7.1 Please try again later
I did a quick search of today's SMTP outbound trace log for the word
"grey" and found this unique grouping of responses:
421 This server implements greylisting, please try again in # seconds
450 4.2.0 <RCPT>: Recipient address rejected: Greylisted, see URL
450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # minutes
450 4.7.1 <RCPT>: Recipient address rejected: Policy Rejection-
Greylisted, please try later (see URL).
450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # minutes
450 4.7.1 <RCPT>: Recipient address rejected: GREYLISTING, please
retry later
450 4.7.1 <RCPT>: Recipient address rejected: Greylisted for # seconds
451 4.7.1 Greylisting in action, please come back in HH:MM:SS
451 4.7.1 Greylisting in action, please come back later
451 Greylisted for # seconds
451 Greylisted, please try again in # seconds
451 Greylisting enabled, try again in # minutes
So you can see there are many using the Harris document. But you see
both 450 and 451 with the 4.7.1 which is probably reflective of
people, including myself, wondering if 450 was better based on what
RFC2821 had for example 45z text:
450 Requested mail action not taken: mailbox unavailable
451 Requested action aborted: error in processing
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
Just based on the text above, one can reasonable use 450 and 451. But
even though 451 for greylisted session wasn't really due to an error
in processing, I went with it as a default because extended codes are
optional. I speculate that was what Harris was thinking too.
Hope this helps.
--
Sincerely
Hector Santos
http://www.santronics.com