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