[RFCI-Discuss] acceptable filtering of RFC2142 mailboxes?

[csmailreport]

On 7/3/06, James Ralston <qralston+ml.rfci-discuss at andrew.cmu.edu> wrote:

> That doesn't seem to be quite the same issue.


I think it's the same issue, except tackled on the other side:

When a spam is sent to james, abuse @example.org,
you let it in even if you know it's most likely a spam
because otherwise you'd be refusing email to abuse@
and so you found out this is a security hole as adding abuse at example.org
to the list of recipients allows them to bypass/disable your spam filters.

We've taken this issue on the other way around:
if you send an email to abuse@ alone, our antispam filters are disabled,
but if you add *any* other recipient, spam filtering gets performed on the
contents of the email, and it may get rejected, because otherwise we'd have
the security hole you just discovered.

As a result, people who email abuse@ + copy any other AOL email address
may get their email refused, and they get us listed on RFCI (cf. previous 2
links).

This is due to SMTP lameness, in that after you've accepted both recipients
because their maildrop exists:
RCPT TO: <jdoe at example.org>
200 OK
RCPT TO: <abuse at example.org>
200 OK
DATA
  <spam here>

at this point there's no way protocol-wise to tell the sender "I'll accept
your email for abuse but not for the other recipients because you're spammy"
-- you can only accept it for all recipients, or refuse it (permanently or
transient) for everyone.

So since SMTP doesn't provide any primitive to indicate partial recipient
delivery at the DATA stage, the transient failure for mixing administrative
mailboxes (alone with antispam disabled) with regular mailboxes where
antispam is implemented is the only workable solution.

In addition, it's transparent to the original sender so they shouldn't even
be aware of the transient failure except for some broken MTAs (yahoogroups
?) -- so the collateral damage will be similar to greylisting.


(Depending on how the recipients are interspersed, of course, it could
> take multiple hours to deliver the message to all recipients, but
> delivery *should* occur eventually.)


Well, shouldn't any piece of email be delivered in at most 2 SMTP
transactions ?
One for the abuse at example.org recipient, one with all others ?

(I'm assuming antispam is enabled on the postmaster mailbox -- this is what
we have, and it's ok RFCI-wise AFAIK -- if you want yet another set of rules
to apply to postmaster versus abuse versus everyone else, that makes it 3
SMTP transactions at most, etc.)

Cheers,
-- Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.megacity.org/pipermail/rfci-discuss/attachments/20060703/97a9e478/attachment.html