On 09/13/2010 08:59 AM, Ian Eiloart wrote: > > > --On 13 September 2010 11:38:39 -0400 "John R. Levine"<[email protected]> > wrote: > >>> --On 13 September 2010 10:19:05 -0400 "MH Michael Hammer (5304)" >>> <[email protected]> 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
