From: Douglas Otis (no email)
Date: Tue Dec 06 2005 - 19:26:16 EST
On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote:
>
> On Tue, 6 Dec 2005, Douglas Otis wrote:
>>
>> 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.
I know of no cases where a malware related DSN would be generated by
our products, nevertheless, DSNs are not Unsolicited Bulk Email.
> 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.
Not all email is rejected within the SMTP session. You are changing
requirements for recipients that scan incoming messages for malware.
Fault them for returning content or not including a null bounce-
address. No one can guarantee an email-address within the bounce-
address is valid, furthermore a DSN could be desired even for cases
where an authorization scheme fails. Why create corner cases?
>> 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.
DomainKeys and Sender-ID can not validate the bounce-address or the
DSN. Even with an SPF failure, a DSN should still be sent, as SPF
fails in several scenarios, and false positives are never 0%. BATV
offers a unilateral option that can effectively discard spoofed
bounce-addresses. When the AV software provides the DSN with a null
bounce-address, BATV works as advertised.
-Doug
|
|
|