Re: draft-ietf-sieve-refuse-reject-07.txt

[Ned Freed <[e-mail]>]

> On Thu May 29 17:22:46 2008, Ned Freed wrote:
> > (1) is only appropriate if the MAIL FROM is emoty, NOTIFY=NEVER is
> > in effect,
> > the MAIL FROM Is somehow known to be forged. That leaves generating
> > a DSN as the only viable alternative in most cases.

> As a brief aside - I agree with both Matthew's aims here and Ned's
> conclusions - it did occur to me that a (possibly LMTP specific)
> response code of some form which indicated both that the mail was
> rejected as was strongly considered to be forged (or otherwise not
> worthwhile to send a DSN for) might be a possibility, although not
> for this document or even working group.

> I suspect that using a 2xx in this case might be best, since it would
> become a "discard", in effect, if the LMTP client didn't understand
> it, and the additional bandwidth and processing for LMTP connections
> is negligable. For SMTP, a 4xx might be more sensible, which would
> reduce the bandwidth, but not generate a DSN instantly.

I pretty much agree with all of this, but now let's take it to the logical
conclusion: If the script has determined that this is probable spam and doesn't
want a response sent, why why not use the guaranteed-to-be-present discard
instead rather than employing the optional-and-doesn't-do-what-you-want
ereject?

The main reason I can think of for wanting to use ereject is that in some sense
it offers a way to log *why* the message was thrown away. But if that's the
goal, surely an extension that allows a <reason> argument to be given to
discard is the better answer. In the LMTP server case this could translate
into sending back a "2yx 5.a.b message discarded because ..." sort of response.

This is why I suggested adding text to the draft saying that these actions are
seriously suboptimal as a means of dealing with spam. I think a little care in
the use of these actions will go a lot further than racketing up the compliance
language further and further. 

				Ned