ietf-smtp
[Top] [All Lists]

Re: Fwd: New Version Notification for draft-macdonald-antispam-registry-00

2010-03-24 18:01:38

Hello Jeff,

already now I do not understand the difference in RFC 3463 between

   X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.  This is useful only as a
         permanent error.

   X.7.2   Mailing list expansion prohibited

         The sender is not authorized to send a message to the intended
         mailing list.  This is useful only as a permanent error.


I mean, when a mail is sent to a mailing list, can X.7.1 be returned? Can X.7.2 be returned, when the mail is not sent to a mailing list? Generally the question is if the recipient likes the sender, here is not relevant if the sender is a mailing list or not.

Your draft adds:

    Code:               X.8.9
    Sample Text:        this recipient will not accept any messages from
                        <IDENTITY>
    Associated Basic Status Code: ????
    Description:        The recipient has chosen to not accept message
                        from IDENTITY.  Administrators MAY include a URL
                        for further details by appending the text with
                        ": see <URL> for further details."

Can you clarify when shall X.7.1 be used, when X.7.2 and when X.8.9?

The firther in my domain I apply the following practice: when I get a spam, it is SMTP-rejected and the result of the SpamAssassin evaluation is concatenated to the result. Sample output:

550-5.7.1 Hello peter(_at_)example(_dot_)org,
550-5.7.1 Your email to spam-evaluation was evaluated as spam and the results are below.
550-5.7.1 ----    ----    ----    ----    ----
550-5.7.1  *  0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
550-5.7.1 * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
550-5.7.1  *      domain
550-5.7.1  *  0.7 FRT_PENIS1 BODY: ReplaceTags: Penis
550-5.7.1  * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1
550-5.7.1  *      [score: 0.0052]
550-5.7.1  *  0.5 MISSING_MID Missing Message-Id: header
550-5.7.1  *  0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
550 5.7.1  *  1.4 MISSING_DATE Missing Date: header.

(You can test it by sending a mail to spam-evaluation(_at_)aegee(_dot_)org, the mails are always returned).

Which of the draft-macdonald-antispam-registry-00 codes shall be used in this case?

Със здраве
  Дилян

На 24.03.2010 17:17, Jeff Macdonald написа:

Hi all,

The following draft put some concepts into words that I brought up a
few years ago. I'd love some commentary on it. Better yet, I'd love
adoption of it. :)


---------- Forwarded message ----------
From: Jeff Macdonald<JMacDonald(_at_)e-dialog(_dot_)com>
Date: Wed, Mar 24, 2010 at 12:12 PM
Subject: Fwd: New Version Notification for draft-macdonald-antispam-registry-00
To: Jeff Macdonald<macfisherman(_at_)gmail(_dot_)com>




Begin forwarded message:

From: IETF I-D Submission Tool<idsubmission(_at_)ietf(_dot_)org>
Date: March 23, 2010 2:19:39 PM EDT
To: Jeff Macdonald<JMacDonald(_at_)e-dialog(_dot_)com>
Subject: New Version Notification for draft-macdonald-antispam-registry-00


A new version of I-D, draft-macdonald-antispam-registry-00.txt has been 
successfully submitted by Jeff Macdonald and posted to the IETF repository.

Filename:      draft-macdonald-antispam-registry
Revision:      00
Title:                 Suggested values for SMTP Enhanced Status Codes for 
Anti-Spam Policy
Creation_date:         2010-03-22
WG ID:                 Independent Submission
Number_of_pages: 13

Abstract:
This document establishes a set of extended SMTP policy codes for
anti-spam. It seeks to provide additional codes for error texts that
currently use the extended SMTP error code 5.7.1. The anti-spam codes
were determined by looking at error texts produced by major ISPs and
finding commonalities. The result is a new set of error texts with
associated extended SMTP error codes.



The IETF Secretariat.







<Prev in Thread] Current Thread [Next in Thread>