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 -----
|
|