ietf-smtp
[Top] [All Lists]

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

2010-03-24 19:43:43


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?

Sure, but given that a more specific error code exists for a list authorization
problem, it's not an ideal value to return.

Can X.7.2 be returned, when the mail is not sent to a mailing list?

Of course it can be, but it's pretty clearly wrong to do so.

Generally the question is if the recipient likes the sender, here is not
relevant if the sender is a mailing list or not.

I don't understand this.

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?

My take is that it's something of a stretch to use 5.7.1 for "I don't like you
please go away" sorts of responses, and having a more specific code for this
particular case isn't a bad thing. OTOH, when there's a failure due to, say. a
rule check or a sieve ereject or whatever, divining the intent in order to make
thi distinction may be impossible. In that case the general error - possibly
even general to the point of 5.7.0 being the right thing - wins.

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?

Without performing an analysis of the SA output and some sort of mapping, I
would say that a fairly generic sort of error is the best you can do. It would
be simple to add a "reject mail unconditionally from this address" rule to SA,
which would pretty clearly be best served by the proposed 5.8.9 code. But a
result like the one you show, which appears to have nothing to do with
rejection on the basis of sender identity information is a pretty clear misfit.

                                Ned

P.S. Please note I'm not advocating for or against the proposed draft here.
These things require careful review before that sort of assessment can be made,
and I haven't done such a review yet.

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