On 09/13/2010 08:59 AM, Ian Eiloart wrote:
--On 13 September 2010 11:38:39 -0400 "John R.
Levine"<johnl(_at_)iecc(_dot_)com>
wrote:
--On 13 September 2010 10:19:05 -0400 "MH Michael Hammer (5304)"
<MHammer(_at_)ag(_dot_)com> wrote:
I agree that if a signing domain publishes discardable then the MLM
should discard it.
If the message is unsigned, right? Otherwise, it should reject it at
SMTP time (actually, that might be done by the MTA rather than the
MLM). In fact the MTA should reject (at SMTP time) rather than discard
such messages, I think.
If it's signed, I agree there's little downside to rejecting it. But
since they said it's discardable, there's little advantage to doing so,
either.
No, there really is an advantage. The sender gets to see that they've tried
to do something that they can't.
A disadvantage is that it requires the SMTP daemon to do a lot of work,
do the whole DKIM validation and ADSP lookup before deciding whether to
reject. You can discard any old time, no need to do it while the TCP
session is open.
No need to, but we do *all* our message scanning, including AV and
spamassassin at SMTP time, because we (a) don't like generating bounce
messages, (b) don't like blackholing, (c) think that spam mailboxes act
like blackholes, and (d) don't want to deliver malware anyway. It doesn't
take a huge resource to do this quite quickly, especially if you reject
early on RBLs.
I really don't know why people who should know better are clinging onto this
nostalgic notion that SMTP-time isn't the right (only) place to do scanning,
but there is a layer violation issue with MLM's. Unless you have a MLM that
is completely purpose-built with SMTP, or has bits and pieces of itself
inserted into
milter-like parts of the SMTP stream, your average MTA is going to have
no clue whether it's destined for a MLM or anything else. So any BCP'ish
language which implied that you should SMTP-500 MLM traffic for ADSP
discardable would be... problematic.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html