ietf-smtp
[Top] [All Lists]

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

2010-03-25 16:15:43

Hello,

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.

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.

You write to an address XXX(_at_)example(_dot_)org . You don't know if this is a mailing list or single-recipient address. Then you get response 5.7.1 or 5.7.2 . Now you know if the address is a mailing list or a single-recipient address.

What sense does it make, when you know now that the destination is a single-recipient address or a mailing list? I even think it is a bad idea to tell the spammer he writes to a mailing list (I hope no spammer will ever read the following paragraph):

In my domain I reject always with 5.7.1 and (for mailing lists with the text) "<env.sender> cannot post to <env.recipient>". This makes a lot of users askig "Why" and I tell them they are not subscribed to the list (when this is the case) with the address they use to post. I could safe me the work of replying to the users and instead return (when appropriate) "<env.sender> cannot post to <env.recipient>, because the address is not subscribed to a mailing list". However the returned messages are SMTP-rejected, rather than bounced, so they are (sometimes) read by the spammers. When you get this information and are somehow intelligent, you check what are the possibilities to subscribe to the mailing list, which entitles you to spam afterwards over the list.

I have to say that in our liberal organization we do not exercize control who subscribes to some lists, neither who is posting over the lists before the message is distributed, so to some lists currently everybody is allowed to subsribe and post. I like it this way and will keep it this way until the spammers start misuse it. By exposing information to the spammer, that the recipient address is a mailing list, I can lead the spammer to the idea to try to subscribe to the mailing list and then spreading spam over it. Returning 5.7.1 (to over intelligent spammers) does not have this risk.

What advantage does it bring to the sender to know that the recipient is a mailing list (5.7.2) and not a single-recipient (5.7.1). For the server-recipient there is a disadvantage, as you can read from the above paragraph.

Actually, writing all this paragraphs, I found the answer of the 5.7.1/5.7.2 question myself: 5.7.2 is appropriate to be returned for mailign lists, where control is exercised over who subscribes the list, and in this case returning additonally the message "<env.sender> cannot post to <env.recipient>, because that address is not subscribed".

The example with the returned spamassassin output and spam-evaluation(_at_)aegee(_dot_)org was not meant as it was understood:

When our mail server gets spam, it is returned with the same error message, that is used by the spam-evaluation(_at_)aegee(_dot_)org address. The question is, when an email to a regular address is evaluated as spam, which code of all shall be used? The question is not which code shall be used by the spam-evaluation(_at_)aegee(_dot_)org service address.

OK, another topic:
 X.7.1 is described with
  "The sender is not authorized to send to the destination.[...]"
 X.8.9 is described with
  "The recipient has chosen to not accept message from IDENTITY.[...]"

For me this is the same- it makes no difference between "the sender is not authorized by the recipient" and "the recipient has choosen".

Ned said to the diff. X.7.1 / X.7.2 / X.8.9 question:

   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.

I think "I don't like you please go away" is for 5.7.0 and writing all this long mail now, I still don't understand the difference between X.7.1 and X.8.9.




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.



----- End message from ned(_dot_)freed(_at_)mrochek(_dot_)com -----