ietf-smtp
[Top] [All Lists]

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

2010-03-25 19:43:55


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.

In most legitimate cases the sender probably does know, and in a significant
number of cases the distinction can be inferred from the local part, e.g,
prius-owners-group(_at_)yahoo(_dot_)org is pretty likely to be a list...

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.

Not exactly. What you know is that the error that's preventing you from sending
to that address is some sort of general authorization failure, versus some kind
of list authorization failure. THis is useful information because it informs
you, the sedner as to what steps may be needed to get authorized.

What sense does it make, when you know now that the destination is a
single-recipient address or a mailing list?

See above.

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

Well, to each his own, but this strikes me as borderline paranoid. Regardless,
if you really believe this is providing aid and comfort to spammers you are of
course free to use a less specific error, to the point of using 5.0.0 for
everything, I suppose.

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.

Again, nobody is forcing you to reveral this information. But a lot of people,
myself included, do not believe this is an issue worth worrying about. We're
willing to accept some risk in exchange for possibly a bit less user confusion.

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.

And so can an email describing the list. Or list archves. Or a web page. Or
whatever. Really, I don't see this as significant information channel for
spmmers in the overall scheme of things.

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.

See above.

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?

Whatever code you believe balances the need to provide useful feedback with
your concern that you're revealing too much to spammers or other undesireables.

These documents are almost entirely descriptive in nature, not proscriptive.
You appear to be adopting the position that they are or should be proscriptive
and then objecting to that behaviior.

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.

I've already done my best to explain what I beleive the difference is.

                                Ned