On Tue, 6 Dec 2005, Douglas Otis wrote: > > > A less than elegant solution as an alternative to deleting the message, is > > > to hold the data phase pending the scan. > > > > Contrary to your vision of this option, it is not only elegant; it happens > > to be the *correct* thing to do. > > Holding at the data phase does usually avoid the need for a DSN, but this > technique may require some added (less than elegant) operations depending upon > where the scan engine exists within the email stream.
Not my problem. I don't need or want, and should not be hammered with, virus "warnings" sent to forged addresses -- ever. They are unsolicited (I didn't request it, and definitely don't want it), bulk (automated upon receipt of viruses by the offending server), e-mail... thus UBE. It's up to the server operator to choose how to handle virus protection in the mail system, without generating any mail whatsoever to forged or unknown-if-it-is-forged senders. > It would seem that when a DSN is required, as a > general practice, the DSN should not include message content. > This should at least thwart this vector being used to spread > malware and spam. Preventing the spread of a virus seems key. I, frankly, don't care about the issue of whether or not a "warning" message includes the virus that triggered it; you've missed the point. I care about the fact that these "warnings" are UBE, at levels that have been peaking above those of direct spam from what I can see. Generated virus "warnings" must not go to a known forged sender, or to a sender for which the forgery status is unknown. If you cannot *guarantee* that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time, your only options are to quarantine, discard, or allow delivery. Do not send a DSN; do not pass Go; do not collect US$200. > There is always BATV to clean-up spoofed bounce-addresses in the meantime. And other methods (DK, SPF, SID, choose your poison). However, if the server cannot verify that the MAIL FROM:<> is not forged with reasonable certainty, the server should not send a DSN, period. Otherwise, it's a direct contributor to the UBE problem. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
