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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>