Re: Clueless anti-virus products/vendors (was Re: Sober)
On Wed, Dec 07, 2005 at 02:15:00PM -0800, Douglas Otis wrote: > >When auth fails, one knows *right then* c/o an SMTP reject. No bounce > >is necessary. > > This assumes all messages are rejected within the SMTP session. Yes, exactly and the point several of us have been making is that this is (a) easy (well, provided you're using a quality MTA; if not, then switch to one) (b) running a sane mail system (c) fast (d) resource-friendly and (e) most important of all, the _only_ way to avoid sending UBE in response to forgeries (which are not going away any time soon or quite possibly ever). (Please note: there are no exceptions to the UBE specification for DSNs. If DSNs are: - sent to forged senders (thus unsolicited) - in bulk (thus bulk) - via email (thus email) then they are UBE, which is THE definition of spam -- and which deliberately omits any mention of content, purpose or other things that are irrelevant to the spam/not-spam question.) ---Rsk
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Thursday 08 Dec 2005 18:08, Douglas Otis wrote:
>
> When accepting messages from anonymous sources, seldom does one know
> the source.
On the contrary, short of the tricks played on AOL to defeat their original
antispam system, TCP means you always know the source.
We manage to filter out ~98% of the unwanted email here with very nearly 100%
accuracy at the SMTP transaction stage with low processor overhead on our new
email servers. At which point any backscatter from what gets through is
trivial, although alas there still is a little due to evil practices of the
past in then forwarding email elsewhere.
But the point of this discussion is that SMTP will have to evolve to be a
point to point system (or functional equivalent). The days of store and
forward in intermediate MTAs should die as quickly as possible (which as our
forwarding demonstrates may be quite slowly alas). The problem is that many
of the antivirus gateways behave like new intermediate MTAs, especially when
for many of the organisations involved it could easily be done during SMTP
transactions.
The remaining issue is how much resource it costs to do your spam/malware
detection, but I believe trying to do anything beyond policy enforcement ("no
EXE/PIF/SCR here please") in terms of malware detection in the MTA is a
mistake, especially when you only really need to protect the thick(!)
clients, and they still need to be protected when the content is
zipped/encrypted/novel/zipped+encrypted+novel etc.
This thread on the other hand should move to Spam-L.
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 8, 2005, at 2:18 AM, [EMAIL PROTECTED] wrote: It seems reasonable to design a mail system so that notifications are sent back to the originator of the message when there is a problem somewhere along the delivery chain. Agreed. The alternative would be more like instant messaging. It seems very UNreasonable to send notifications to random destinations that have nothing to do with originating the message in question. It is also unreasonable to assume the return-path can always be associated with the sending MTA. The crux of the matter is that if you don't KNOW the true source of the message, then you cannot return a DSN. You can go through the motions, but then you are originating SPAM (UBE), not returning DSNs. When accepting messages from anonymous sources, seldom does one know the source. Should you be accepting any mail at all from SMTP servers that you do not know and trust because of prior contact, i.e. negotiating an email peering agreement? Making email a closed system would dramatically change who can send messages and how email would work. The safest place to decide whether a DSN is legitimate is by the MTA located by the return- path. Use of BATV allows the return-path MTA to immediately refuse DSNs determined to be illegitimate. Immediately, the back-scatter problem would be substantially resolved and no RFC need to be changed, and the integrity of email delivery would not suffer. This would also close the "back-door" used to evade black-hole lists. -Doug
Re: Clueless anti-virus products/vendors (was Re: Sober)
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Thu 08 Dec 2005, 12:11 CET]: The RFC process itself is broken when clueless vendors treat RFCs as inviolable specs and implement according to the RFC even when they find flaws in it. If they want to remain true to the RFC process, they should not implement dumb things found in an RFC, instead they should write and submit a new RFC correcting the error and explaining the right way to do things. Exactly. The nice thing about standards is that there are so many to choose from! Why not add a few more? -- Niels. -- "Calling religion a drug is an insult to drugs everywhere. Religion is more like the placebo of the masses." -- MeFi user boaz
Re: Clueless anti-virus products/vendors (was Re: Sober)
> Perhaps DSNs should be sent to the original recipient, not the purported > sender. RFC-compliant? No. The RFC process itself is broken when clueless vendors treat RFCs as inviolable specs and implement according to the RFC even when they find flaws in it. If they want to remain true to the RFC process, they should not implement dumb things found in an RFC, instead they should write and submit a new RFC correcting the error and explaining the right way to do things. --Michael Dillon
Re: Clueless anti-virus products/vendors (was Re: Sober)
> Some may see it as a > violation of RFC to not return a DSN on failed delivery. It seems reasonable to design a mail system so that notifications are sent back to the originator of the message when there is a problem somewhere along the delivery chain. > Others, like myself > see the need to not return a failure notice on virus / trojan infected email > as it has become the norm that the sender information is forged. It seems very UNreasonable to send notifications to random destinations that have nothing to do with originating the message in question. The crux of the matter is that if you don't KNOW the true source of the message, then you cannot return a DSN. You can go through the motions, but then you are originating SPAM (UBE), not returning DSNs. Should you be accepting any mail at all from SMTP servers that you do not know and trust because of prior contact, i.e. negotiating an email peering agreement? --Michael Dillon
Re: Clueless anti-virus products/vendors (was Re: Sober)
DO> Date: Wed, 7 Dec 2005 17:02:51 -0800 DO> From: Douglas Otis DO> > H. BATV-triggered bounces. Virus triggers forged bounce which in DO> > turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth DO> > growth of the '90s will continue. ;-) DO> DO> BATV should not trigger any bounce as this only changes the local-part of DO> the bounce-address (a.k.a return-path). BATV allows quick rejection of the DO> session when a spoof is detected before any message is exchanged. This I've read the spec. DO> should alleviate your concerns about bandwidth. It would also depreciate I usually don't use humor-related smileys when I'm worried. DO> this tactic and further reduce related traffic. Being sensitive about DO> spoofed DSNs, one would expect to hear accolades for BATV rather than DO> berating. Wouldn't it be nice to let people know their DSNs are misplaced? Or does that only apply to viruses and worms? ;-) So much for "be conservative in what you send and liberal in what you accept". Yes, BATV helps block the errant DSNs. It's just a shame that we seem to be shifting responsibility to the recipient, treating the symptom instead of the disease. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 7, 2005, at 4:06 PM, Edward B. Dreger wrote: H. BATV-triggered bounces. Virus triggers forged bounce which in turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth growth of the '90s will continue. ;-) BATV should not trigger any bounce as this only changes the local- part of the bounce-address (a.k.a return-path). BATV allows quick rejection of the session when a spoof is detected before any message is exchanged. This should alleviate your concerns about bandwidth. It would also depreciate this tactic and further reduce related traffic. Being sensitive about spoofed DSNs, one would expect to hear accolades for BATV rather than berating. -Doug
Re: Clueless anti-virus products/vendors (was Re: Sober)
DO> Date: Wed, 7 Dec 2005 14:15:00 -0800 DO> From: Douglas Otis DO> > Perhaps DSNs should be sent to the original recipient, not the purported DO> > sender. RFC-compliant? No. Ridiculous? Less so than pestering a DO> > random third party. Let the intended recipient communicate OOB or DO> > manually if needed. DO> DO> Being refused by the intended recipient would be the cause for the DSN. Fine. But where to send it? Certainly not to a random address. DO> > DO> furthermore a DSN could be desired even for cases where an DO> > authorization DO> > DO> > When auth fails, one knows *right then* c/o an SMTP reject. No bounce DO> > is necessary. DO> DO> This assumes all messages are rejected within the SMTP session. Perhaps we're examining different "authorization" cases. Maybe my mindset of "SMTP auth" is too narrow for your intended scope. DO> > DO> scheme fails. Why create corner cases? DO> > DO> > The corner case is that a virus _might_ actually have a realistic "From" DO> > address. :-) DO> DO> You mean bounce-address? A From address often has nothing to do with where DO> a message originated. DO> DO> SPF has _nothing_ to do with the From address. E, "return-path". Freudian slip dealing with some site local experiments... "from" is not as accurate as "return-path", but it's far from (no pun intended) useless. DO> Once again, not _all_ messages are rejected within the SMTP session. False Of course not. DO> positives are not 0%. To ensure the integrity of email delivery, not DO> including message content and using a null bounce-address should be the DO> recommended practice at the initial recipient. If you do not want to see DO> DSNs with spoofed bounce-addresses, employ BATV at _your_ end should be the DO> recommended practice. You would not need to insist that anything special be DO> done at millions of other locations. Oh well. I guess I've pretty much given up on pre-body filtering... so I suppose it would be too idyllic to expect anything different with DSNs. H. BATV-triggered bounces. Virus triggers forged bounce which in turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth growth of the '90s will continue. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 7, 2005, at 1:35 PM, Edward B. Dreger wrote: DO> Not all email is rejected within the SMTP session. You are changing DO> requirements for recipients that scan incoming messages for malware. Fault DO> them for returning content or not including a null bounce- address. No one DO> can guarantee an email-address within the bounce-address is valid, Perhaps DSNs should be sent to the original recipient, not the purported sender. RFC-compliant? No. Ridiculous? Less so than pestering a random third party. Let the intended recipient communicate OOB or manually if needed. Being refused by the intended recipient would be the cause for the DSN. DO> furthermore a DSN could be desired even for cases where an authorization When auth fails, one knows *right then* c/o an SMTP reject. No bounce is necessary. This assumes all messages are rejected within the SMTP session. DO> scheme fails. Why create corner cases? The corner case is that a virus _might_ actually have a realistic "From" address. :-) You mean bounce-address? A From address often has nothing to do with where a message originated. DO> DomainKeys and Sender-ID can not validate the bounce-address or the DSN. DO> Even with an SPF failure, a DSN should still be sent, as SPF fails in If you receive mail with From: <[EMAIL PROTECTED]> coming from 10.10.10.10, and everquick.net SPF records indicate that IP address is bogus, how can you possibly justify "that mail may indeed have come from how it's apparently addressed"? Doubly so when a virus is known to spoof "from" addresses! SPF has _nothing_ to do with the From address. Once again, not _all_ messages are rejected within the SMTP session. False positives are not 0%. To ensure the integrity of email delivery, not including message content and using a null bounce- address should be the recommended practice at the initial recipient. If you do not want to see DSNs with spoofed bounce-addresses, employ BATV at _your_ end should be the recommended practice. You would not need to insist that anything special be done at millions of other locations. -Doug
Re: Clueless anti-virus products/vendors (was Re: Sober)
DO> Date: Tue, 6 Dec 2005 16:26:16 -0800 DO> From: Douglas Otis DO> I know of no cases where a malware related DSN would be generated by our Good. DO> products, nevertheless, DSNs are not Unsolicited Bulk Email. Huh? I get NDRs for mail that "I" sent. I do not want those NDRs. I did not request those NDRs. Those NDRs are not in response to a message I sent. I do not want backscatter NDR notices. I frankly don't care that WhizBangAV caught WormOfTheWeek on Susie Smith's corporate mail in Argentina from Billy Boo's PC in China... just because my address happened to be the subject of a joe jobbing worm. Really. Even reading and posting to NANOG is more important. ;-) DO> Not all email is rejected within the SMTP session. You are changing DO> requirements for recipients that scan incoming messages for malware. Fault DO> them for returning content or not including a null bounce-address. No one DO> can guarantee an email-address within the bounce-address is valid, Perhaps DSNs should be sent to the original recipient, not the purported sender. RFC-compliant? No. Ridiculous? Less so than pestering a random third party. Let the intended recipient communicate OOB or manually if needed. DO> furthermore a DSN could be desired even for cases where an authorization When auth fails, one knows *right then* c/o an SMTP reject. No bounce is necessary. DO> scheme fails. Why create corner cases? The corner case is that a virus _might_ actually have a realistic "From" address. :-) DO> DomainKeys and Sender-ID can not validate the bounce-address or the DSN. DO> Even with an SPF failure, a DSN should still be sent, as SPF fails in If you receive mail with From: <[EMAIL PROTECTED]> coming from 10.10.10.10, and everquick.net SPF records indicate that IP address is bogus, how can you possibly justify "that mail may indeed have come from how it's apparently addressed"? Doubly so when a virus is known to spoof "from" addresses! Saying a DSN should be sent is just untenable. DO> several scenarios, and false positives are never 0%. BATV offers a DO> unilateral option that can effectively discard spoofed bounce-addresses. DO> When the AV software provides the DSN with a null bounce-address, BATV works DO> as advertised. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Tue, 6 Dec 2005, Douglas Otis wrote: > > 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, That's good. Unfortunately it is not the case for most commercial anti-malware products. > nevertheless, DSNs are not Unsolicited Bulk Email. I don't see how this is relevant to my paragraph above. I was not equating DSNs to UBE -- I specifically mentioned virus "warnings". Whether those warnings are look like DSNs, smell like DSNs, or taste like DSNs is wholly irrelevant; they are still UBE if sent to forged virus sender addresses. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Todd Vierling" <[EMAIL PROTECTED]> Cc: "Steven M. Bellovin" <[EMAIL PROTECTED]>; "Church, Chuck" <[EMAIL PROTECTED]>; Sent: Tuesday, December 06, 2005 6:26 PM Subject: Re: Clueless anti-virus products/vendors (was Re: Sober) 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. That's good Doug, and IMHO, your products should never generate them. However, I will disagree with you concerning the DSN being UBE. As a general rule, you are correct, DSN's != UBE. However, in the case of av systems (scanning engine and mta configurations) they can be. While I agree with you that the scanning engine(s) used by most of us, do not actually send reject notifications, the mechanisms that employ them, both commercial and open source, usually can, and do, unless configured not to. Some may see it as a violation of RFC to not return a DSN on failed delivery. Others, like myself see the need to not return a failure notice on virus / trojan infected email as it has become the norm that the sender information is forged. Especially those systems that contain the infected data along with the message. To many trojans / viri as of late, the DSN's that include the message (with infection) are being used as a repeater to further propogate the infection. Those that release these things are starting to depend on our mechanisms to help them spread. I, like others, prefer not to help them break the net from my little piece of it. -- Mike P.
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Tue, 6 Dec 2005, Douglas Otis wrote: > > 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. Rght. Virus notifications aren't DSNs. 99% of the time, they're ads for the publisher of whatever anti-virus filter is being used on the recipient's side. -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
Re: Clueless anti-virus products/vendors (was Re: Sober)
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
Re: Clueless anti-virus products/vendors (was Re: Sober)
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]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 6, 2005, at 8:19 AM, Todd Vierling wrote: On Mon, 5 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. Waiting for the scan to complete adds stack overhead (assuming a good black-hole list is being used). Albeit small, there is never 0% false detections of malware. 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. There is always BATV to clean-up spoofed bounce-addresses in the meantime. -Doug
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Mon, 5 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. Dropping the message on the floor is arguably stretching the bounds of RFC2821. If a message is going to be dropped because of a policy (such as a worm/virus flag), you really should be rejecting after DATA with a RFC1893 5.7.x extended result code. > Another solution would be not returning message content within a DSN. If you're still sending to a forged address, how is this not still UBE...? -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Mon, 05 Dec 2005 17:38:00 PST, Douglas Otis said: > pending the scan. Another solution would be not returning message > content within a DSN. This would mitigate the distribution of > viruses, as well as forged bounce-addresses sent to a backup MTAs as > a method for bypassing black-hole lists. Would changing what is > returned within a DSN in all cases be a solution? No. You're still sending a DSN to a destination that you know beforehand is incorrect. pgpIsMlepDe2K.pgp Description: PGP signature
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 4, 2005, at 8:04 PM, Steven M. Bellovin wrote: "Church, Chuck" writes: The ideal solution would be for the scanning software to send a warning only if the virus detected is known to use real addresses, otherwise it won't warn. A-V companies are in the business of analyzing viruses. They should *know* how a particular virus behaves. It is common to find detailed descriptions offered by the company that indicates the behavior of the detected virus, which often includes spoofing the bounce-address. A less than elegant solution as an alternative to deleting the message, is to hold the data phase pending the scan. Another solution would be not returning message content within a DSN. This would mitigate the distribution of viruses, as well as forged bounce-addresses sent to a backup MTAs as a method for bypassing black-hole lists. Would changing what is returned within a DSN in all cases be a solution? -Doug
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, Dec 04, 2005 at 09:27:58PM -0600, Church, Chuck wrote: > What about all the viruses out there that don't forge addresses? Three responses. First, these are pretty much a minority nowadays: so unless someone wants to code AV responses on a case-by-case basis, the best default is "don't respond, ever". Second, rejecting virus-contaminated traffic during the SMTP phase completely alleviates the need to address this question, since no outbound mail is generated. Third, put the first two points aside. Let's suppose, for a moment, that there existed a completely reliable mechanism for figuring out the real sender (in the sense of "the owner of the infected system") for a particular virus-contaminated message. Think about what would happen if the 100 or 1000 or 1 or 10 people getting outbound viruses from that user all generated responses. The first effect would be to double the quantity of useless mail messages traversing the Internet. The second effect would be to hammer the user's mailbox and whatever mail server it happened to be residing on. (Consider how this effect would be multiplied if many users of X all had infected systems sending SMTP traffic directly, but of course were all receiving inbound mail via X's mail server(s).) The third effect would really be a non-effect, as the user's most likely response (thanks to years of conditioning imposed by the problem we're discussing here) would be to do nothing: experience has taught users that such warnings are bogus and can safely be ignored. The user's second-most-likely response would be indignant denial (despite logs showing positive identification). The user's third-most-likely response would be report the responses as spam and/or block the senders. Bottom line: nothing good can come of generating outbound mail in response to rejected inbound mail; the best course of action is to issue the appropriate 5XX response and be done with it. ---Rsk
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, Dec 04, 2005 at 03:18:29PM -0800, Steve Sobol wrote: > Blocking based on rDNS simply because it implies that a certain piece of > equipment is at that address is... not advisable. Agreed. Those blocks aren't in place because there's a certain piece of equipment at those addresses (hostnames); they're in place because all of them have emitted spam. ---Rsk
RE: Clueless anti-virus products/vendors (was Re: Sober)
At 10:27 PM 12/4/2005, Church, Chuck wrote: What about all the viruses out there that don't forge addresses? As others have noted, these are so far lost in the noise as to not be a factor. Sending a warning message makes sense for these. Why? Because you need to be the one to tell the sender they are infected? Let sites patrol their own users. Furthermore, if you did your virus scanning during the SMTP transaction, you'd be able to send back a 5xx error response during the transaction, thereby avoiding any concern about spamming an innocent third party. Unless someone has done the research to determine the majority of viruses forge addresses, you really can't complain about the fact that the default is to warn. As others have noted, the vendors can and should know. Calling vendors 'clueless' because a default doesn't match your needs Excuse me, I think you may notice that a LOT of folks have piped up on this issue. The simple fact is as configured many vendors spam third parties adding to the noise floor. While backbone operators might in fact make a bit extra as a result, those of us who actually pay for bandwidth do not appreciate it. We certainly can and do blacklist sites that hammer us with bogus bounces, just the same as we'd block any company knowingly sending us undesired email. is a little extreme, don't you think? The ideal solution would be for the scanning software to send a warning only if the virus detected is known to use real addresses, otherwise it won't warn. See question above, re: why do you think it's your systems' place to police the rest of the Internet, sending warnings out? Either reject virus-laden email during the SMTP session, or quietly own it (and dispose of it). Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Vierling Sent: Sunday, December 04, 2005 4:53 PM To: W.D.McKinney Cc: nanog@merit.edu Subject: RE: Clueless anti-virus products/vendors (was Re: Sober) On Sun, 4 Dec 2005, W.D.McKinney wrote: > > (Virus "warnings" to forged addresses are UBE, plain and simple.) > > Since when? I disagree. UBE = "unsolicited bulk e-mail". Which of those three words do[es] not apply to virus "warning" backscatter to forged envelope/From: addresses? Think carefully before answering. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
> From [EMAIL PROTECTED] Sun Dec 4 22:34:54 2005 > Date: Mon, 05 Dec 2005 04:30:26 + (GMT) > From: "Christopher L. Morrow" <[EMAIL PROTECTED]> > Subject: Re: Clueless anti-virus products/vendors (was Re: Sober) > To: "Steven M. Bellovin" <[EMAIL PROTECTED]> > Cc: "Church, Chuck" <[EMAIL PROTECTED]>, nanog@merit.edu > > > On Sun, 4 Dec 2005, Steven M. Bellovin wrote: > > > In message <[EMAIL PROTECTED]>, "Chur > > ch, Chuck" writes: > > > > > >What about all the viruses out there that don't forge addresses? > > >Sending a warning message makes sense for these. Unless someone has > > > > A-V companies are in the business of analyzing viruses. They should > > *know* how a particular virus behaves. > > This has also been said before, but... they are also in the business of > SELLING their product. It seems that the 'default' (note I don't either: > use av, nor scan emails for virii so I'm not sure what defaults to what... > just use something other than outlook and you can care less about it) is > possibly there for advertising effect more than anything else :( > > Hey, bob's company stopped this virus with $PRODUCT_12, why aren't we > using that product $VP_O_IT ?? "Because they 'very thoughtfully' fowarded the entire message, INCLUDING THE VIRUS ITSELF, to us. _Even_though_ the original message did not originate here. "Do you _really_ think we should start forwarding viruses to our customers, 'just because' their address was forged into a message sent us? Just how do you think our customers would respond to _that_?" There _is_ an art-form to backing management into an untennable corner, when they are bound and determined to do something 'wrong'. It's simply a matter of finding the "right" consequences of the action, to illustrate _why_ the proposed thing is 'wrong'. 'Revenues', and 'customer satisfaction' are almost _universal_ "hot buttons" that can frequently be used to advantage.
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, 4 Dec 2005, Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, "Chur > ch, Chuck" writes: > > > >What about all the viruses out there that don't forge addresses? > >Sending a warning message makes sense for these. Unless someone has > > A-V companies are in the business of analyzing viruses. They should > *know* how a particular virus behaves. This has also been said before, but... they are also in the business of SELLING their product. It seems that the 'default' (note I don't either: use av, nor scan emails for virii so I'm not sure what defaults to what... just use something other than outlook and you can care less about it) is possibly there for advertising effect more than anything else :( Hey, bob's company stopped this virus with $PRODUCT_12, why aren't we using that product $VP_O_IT ??
RE: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, 4 Dec 2005, Church, Chuck wrote: > What about all the viruses out there that don't forge addresses? Not that there are nearly as many -- the main scourge is sender-forging worms by a better than 90%/10% margin -- but I very specifically mentioned: > > > (Virus "warnings" to forged addresses are UBE, plain and simple.) I think that was pretty clear. > Sending a warning message makes sense for these. Unless someone has > done the research to determine the majority of viruses forge addresses, Are you living on Earth in 2005? Unless your filters are VERY strict, no research should be necessary; look at your own mailbox[es]. If you don't know that most worm-viruses forge senders these days, you haven't been using Internet e-mail long enough. 8-) That said, it takes only a cursory glance through the worms listed on Symantec's or F-Secure's or Sophos's web sites in reverse chronological order to see, very clearly, that *nearly every* worm in recent history forges sender addresses. Finding three or more worms in the past two years that don't forge is a challenge for the bored reader. Some do it for a very good reason -- in the eyes of the worm's writer, mind you. A worm is more likely to get through if the user in envelope-FROM has some sort of relationship with the recipient, because so many sites use weighted scoring that includes auto-whitelist bias. To a worm writer, just using the address in the luser's settings isn't enough, as folks are starting to understand "don't click on any random attachment." So, gambling on the luser having a circle of friends close enough to know each other, the worm forges many different combinations. (If you want more details on this reasoning, take it off-list.) > Calling vendors 'clueless' because a default doesn't match your needs is > a little extreme, don't you think? The vendors sending worm-virus "warning" UBE are indeed clueless now, because they aren't paying attention to (often their own!) virus statistics showing that the majority of worm-viruses forge sender addresses today. Let me repeat myself: > > > (Virus "warnings" to forged addresses are UBE, plain and simple.) Not sending UBE is not just "my needs"; I think we can both agree on that. To extend that concept, virus "warnings" triggered by worm-viruses for which the forgery status is unknown is either UBE or very close to it. With the massive amount if spew that is forged, any warning option that is not absolutely confined to trigger on problem mail *known* not to be forged is a part of the problem, not part of the solution. The option for warning on forged senders shouldn't just be off -- it should not exist. > The ideal solution would be for the scanning software to send a warning > only if the virus detected is known to use real addresses, otherwise it > won't warn. Symantec reportedly did this at long last in one of their products recently (see [EMAIL PROTECTED] archives for details). I truly hope others follow suit. However, unless the option to warn forged senders is removed entirely from their products, anti-malware vendors still have a large amount of fault on their shoulders. Things like clamav have had the option properly separated for some time, but I'm mainly counting the slow-moving, commercial anti-malware products in the prior pragraph. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
An even more cynical way would be to say that most antivirus companies aren't in the business of analyzing viruses - they are in the business of selling antivirus software. I believe that is the fundamental problem. Jamie -- Jamie C. Pole [EMAIL PROTECTED] http://www.jcpa.com InfoSec / InfoWar / Forensics On Dec 4, 2005, at 11:18 PM, Edward B. Dreger wrote: SMB> Date: Sun, 04 Dec 2005 23:04:52 -0500 SMB> From: Steven M. Bellovin SMB> A-V companies are in the business of analyzing viruses. They should SMB> *know* how a particular virus behaves. The cynical would say they _do_ know, and "accidental" backscatter is a way to advertise their products. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita __ __ DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
SMB> Date: Sun, 04 Dec 2005 23:04:52 -0500 SMB> From: Steven M. Bellovin SMB> A-V companies are in the business of analyzing viruses. They should SMB> *know* how a particular virus behaves. The cynical would say they _do_ know, and "accidental" backscatter is a way to advertise their products. ;-) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Clueless anti-virus products/vendors (was Re: Sober)
In message <[EMAIL PROTECTED]>, "Chur ch, Chuck" writes: > >What about all the viruses out there that don't forge addresses? >Sending a warning message makes sense for these. Unless someone has >done the research to determine the majority of viruses forge addresses, >you really can't complain about the fact that the default is to warn. >Calling vendors 'clueless' because a default doesn't match your needs is >a little extreme, don't you think? The ideal solution would be for the >scanning software to send a warning only if the virus detected is known >to use real addresses, otherwise it won't warn. > A-V companies are in the business of analyzing viruses. They should *know* how a particular virus behaves. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sunday 04 December 2005 21:27, Church, Chuck wrote: > What about all the viruses out there that don't forge addresses? > Sending a warning message makes sense for these. Unless someone has > done the research to determine the majority of viruses forge addresses, > you really can't complain about the fact that the default is to warn. > Calling vendors 'clueless' because a default doesn't match your needs is > a little extreme, don't you think? The ideal solution would be for the > scanning software to send a warning only if the virus detected is known > to use real addresses, otherwise it won't warn. True, but the "capability" has been in most AV software for quite a long time now to know which ones "forge" and which do not. Clamav has a "list" of which virii are "forging" and which are not - I am reasonably certain that most other AV products have the same information at hand (a quick search of Symantec confirms that they know [ref sober worm, para 23, From: (spoofed)). So while I agree with your basic concept of notifying someone that they are infected - when you can notify the "right" person - blanket notifications are more trouble than the virus itself in many cases. And yes, as of yesterday I have more "blowback" from sober than from the worm itself -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
Re: Clueless anti-virus products/vendors (was Re: Sober)
Better safe than sorry. Unless you can determine that it isn't forged, you shouldn't be sending anything because there is so much out there forging From: addresses (or To: for that matter, with Bcc:). So, this isn't about ideal vs ok-close-enough. Don't send me crap unless you have a reasonable level of confidence. I don't believe that you can pass a straight face test with virus scanning responses on that one. If you can, I think you need your head examined ;-) On Dec 4, 2005, at 10:27 PM, Church, Chuck wrote: What about all the viruses out there that don't forge addresses? Sending a warning message makes sense for these. Unless someone has done the research to determine the majority of viruses forge addresses, you really can't complain about the fact that the default is to warn. Calling vendors 'clueless' because a default doesn't match your needs is a little extreme, don't you think? The ideal solution would be for the scanning software to send a warning only if the virus detected is known to use real addresses, otherwise it won't warn. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Vierling Sent: Sunday, December 04, 2005 4:53 PM To: W.D.McKinney Cc: nanog@merit.edu Subject: RE: Clueless anti-virus products/vendors (was Re: Sober) On Sun, 4 Dec 2005, W.D.McKinney wrote: (Virus "warnings" to forged addresses are UBE, plain and simple.) Since when? I disagree. UBE = "unsolicited bulk e-mail". Which of those three words do[es] not apply to virus "warning" backscatter to forged envelope/From: addresses? Think carefully before answering. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
>>What about all the viruses out there that don't forge addresses? What virus in the past 2 years doesn't forge the from address? George Roettger
RE: Clueless anti-virus products/vendors (was Re: Sober)
What about all the viruses out there that don't forge addresses? Sending a warning message makes sense for these. Unless someone has done the research to determine the majority of viruses forge addresses, you really can't complain about the fact that the default is to warn. Calling vendors 'clueless' because a default doesn't match your needs is a little extreme, don't you think? The ideal solution would be for the scanning software to send a warning only if the virus detected is known to use real addresses, otherwise it won't warn. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Vierling Sent: Sunday, December 04, 2005 4:53 PM To: W.D.McKinney Cc: nanog@merit.edu Subject: RE: Clueless anti-virus products/vendors (was Re: Sober) On Sun, 4 Dec 2005, W.D.McKinney wrote: > > (Virus "warnings" to forged addresses are UBE, plain and simple.) > > Since when? I disagree. UBE = "unsolicited bulk e-mail". Which of those three words do[es] not apply to virus "warning" backscatter to forged envelope/From: addresses? Think carefully before answering. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
> From [EMAIL PROTECTED] Sun Dec 4 17:19:43 2005 > Date: Sun, 04 Dec 2005 15:18:29 -0800 > From: Steve Sobol <[EMAIL PROTECTED]> > To: Rich Kulawiec <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: Clueless anti-virus products/vendors (was Re: Sober) > > > Rich Kulawiec wrote: > > > And thus we now have blacklist entries such as: > > > > barracuda1.aus.texas.net > > barracuda.yale-wrexham.ac.uk > > barracuda.morro-bay.ca.us > > barracuda.ci.mtnview.ca.us > > barracuda.elbert.k12.ga.us > > barracuda.fort-dodge.k12.ia.us > > barracuda.ci.garner.nc.us > > barracuda.ship.k12.pa.us > > > > and many, many more. > > Blocking based on rDNS simply because it implies that a certain piece of > equipment is at that address is... not advisable. _UNTIL_ the first backscatter arrives from 'that' equipment, that is. *wry*grin*
Re: Clueless anti-virus products/vendors (was Re: Sober)
Rich Kulawiec wrote: And thus we now have blacklist entries such as: barracuda1.aus.texas.net barracuda.yale-wrexham.ac.uk barracuda.morro-bay.ca.us barracuda.ci.mtnview.ca.us barracuda.elbert.k12.ga.us barracuda.fort-dodge.k12.ia.us barracuda.ci.garner.nc.us barracuda.ship.k12.pa.us and many, many more. Blocking based on rDNS simply because it implies that a certain piece of equipment is at that address is... not advisable. -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
RE: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, 4 Dec 2005, W.D.McKinney wrote: > > (Virus "warnings" to forged addresses are UBE, plain and simple.) > > Since when? I disagree. UBE = "unsolicited bulk e-mail". Which of those three words do[es] not apply to virus "warning" backscatter to forged envelope/From: addresses? Think carefully before answering. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sun, Dec 04, 2005 at 09:58:20AM -0500, Todd Vierling wrote: > If it is on by default, it is a bug, and not operator error. (In the case of the Barracuda) there are at least two such switches: one for spam, one for viruses. Note that when both are set to "off" that the box still occasionally emits such messages under as-yet-undetermined circumstances. I attempted to persuade one of Barracuda's engineers, months ago, that there was absolutely no valid reason for including a "feature" whose only purpose was abuse redirection. Incredibly, I was told "the customers want this feature", and that it would not be removed. And thus we now have blacklist entries such as: barracuda1.aus.texas.net barracuda.yale-wrexham.ac.uk barracuda.morro-bay.ca.us barracuda.ci.mtnview.ca.us barracuda.elbert.k12.ga.us barracuda.fort-dodge.k12.ia.us barracuda.ci.garner.nc.us barracuda.ship.k12.pa.us and many, many more. Perhaps Barracuda should simply rename those switches as "spam random individuals" and/or "get yourself blacklisted", as those are the only two things likely to result from turning them on. > (Virus "warnings" to forged addresses are UBE, plain and simple.) When sent in bulk (as they inevitably are), absolutely. There's no exception in the canonical definition of spam (which _is_ "UBE") for "messages sent by broken anti-virus software", nor should there be. ---Rsk
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Dec 4, 2005, at 2:06 PM, W.D.McKinney wrote: Can people building virus scanning devices PLEASE GET A %^&*^ CLUE? This means you, Barricuda Networks, more than anyone else, but we also see this annoyance from Symantec devices, and from some AOL systems as well. It's a simple switch in the GUI of Barracuda Networks to turn of this annoyance. More operator error than Barracuda's fault, IMHO. If it is on by default, it is a bug, and not operator error. (Virus "warnings" to forged addresses are UBE, plain and simple.) Since when? I disagree. While we can argue whether it is UBE, it is a pretty dumb move I think we can all agree.. ;-)
RE: Clueless anti-virus products/vendors (was Re: Sober)
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Todd Vierling > Sent: Sunday, December 04, 2005 5:58 AM > To: W.D.McKinney > Cc: [EMAIL PROTECTED] > Subject: Re: Clueless anti-virus products/vendors (was Re: Sober) > > > On Sat, 3 Dec 2005, W.D.McKinney wrote: > > > >Can people building virus scanning devices PLEASE GET A %^&*^ CLUE? > > >This means you, Barricuda Networks, more than anyone else, but we > > >also see this annoyance from Symantec devices, and from some AOL > > >systems as well. > > > > It's a simple switch in the GUI of Barracuda Networks to turn of this > > annoyance. More operator error than Barracuda's fault, IMHO. > > If it is on by default, it is a bug, and not operator error. > > (Virus "warnings" to forged addresses are UBE, plain and simple.) > Since when? I disagree. -Dee
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sat, 3 Dec 2005, W.D.McKinney wrote: > >Can people building virus scanning devices PLEASE GET A %^&*^ CLUE? > >This means you, Barricuda Networks, more than anyone else, but we > >also see this annoyance from Symantec devices, and from some AOL > >systems as well. > > It's a simple switch in the GUI of Barracuda Networks to turn of this > annoyance. More operator error than Barracuda's fault, IMHO. If it is on by default, it is a bug, and not operator error. (Virus "warnings" to forged addresses are UBE, plain and simple.) -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Clueless anti-virus products/vendors (was Re: Sober)
On 12/3/05, Daniel Senie <[EMAIL PROTECTED]> wrote: > Can people building virus scanning devices PLEASE GET A %^&*^ CLUE? > This means you, Barricuda Networks, more than anyone else, but we > also see this annoyance from Symantec devices, and from some AOL > systems as well. The worst offenders that I see - MailMarshal eSafe Symantec devices, as you say Comparatively little from Barracudas. And some large carriers / ISPs who send bounces / virus notifications back with (for example) [EMAIL PROTECTED] as the return path instead of MAIL FROM:<>
RE: Clueless anti-virus products/vendors (was Re: Sober)
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Richard Cox > Sent: Friday, December 02, 2005 4:23 PM > To: [EMAIL PROTECTED] > Subject: Re: Clueless anti-virus products/vendors (was Re: Sober) > > > On Sat, 03 Dec 2005 00:45:05 + > "W.D.McKinney" <[EMAIL PROTECTED]> wrote: > > It's a simple switch in the GUI of Barracuda Networks to turn of > > this annoyance. More operator error than Barracuda's fault, IMHO. > > Not if a software upgrade from Barracuda can cause the current > configuration to be silently reverted to Barracuda's defaults ... That never happened on any of our cluster. -Dee > > -- > Richard
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Sat, 03 Dec 2005 00:45:05 + "W.D.McKinney" <[EMAIL PROTECTED]> wrote: > It's a simple switch in the GUI of Barracuda Networks to turn of > this annoyance. More operator error than Barracuda's fault, IMHO. Not if a software upgrade from Barracuda can cause the current configuration to be silently reverted to Barracuda's defaults ... -- Richard
Re: Clueless anti-virus products/vendors (was Re: Sober)
>-Original Message- >From: Daniel Senie [mailto:[EMAIL PROTECTED] >Sent: Friday, December 2, 2005 11:27 AM >To: [EMAIL PROTECTED] >Subject: Clueless anti-virus products/vendors (was Re: Sober) > > >At 03:12 PM 12/2/2005, Michael Loftis wrote: > > > >>--On December 2, 2005 2:02:15 PM -0600 Dennis Dayman >><[EMAIL PROTECTED]> wrote: >> >>> >>>Interested, but I see many Sober postings and outages on other lists and >>>not here...has anyone been having issues? I know the ISP's are fighting >>>the living out of the virus. >> >>I've been seeing a few really large bursts into our mailserver. Not >>sure if it's a new variant or a reoccurrence of an old strain. I >>put in a good number of new port 25 inbound blocks for infected >>systems and attempted to put up a few checks inside of our front end >>mail servers rather than in the virus and spam filtering (which >>happens later for us, so for bad surges we put a few custom rules up >>front early in postfix). > >Only stuff we're seeing is a lot of blowback from dumb mail systems >that accept email, THEN scan for viruses, and ultimately decide to >send a note back to the From: address in the body of the infected >email. Since the From: is invariably forged, the uninvolved owner of >those forged email addresses gets hammered. > >Can people building virus scanning devices PLEASE GET A %^&*^ CLUE? >This means you, Barricuda Networks, more than anyone else, but we >also see this annoyance from Symantec devices, and from some AOL >systems as well. > It's a simple switch in the GUI of Barracuda Networks to turn of this annoyance. More operator error than Barracuda's fault, IMHO. -Dee >Blasting a note back does two things: > >1. It allows the worm or virus author an opportunity to implement an >amplified attack on a third party using your filtering systems. > >2. The bounce messages mostly include an advertisement for the >filtering box's vendor. Get a clue... this is a REALLY negative >advertisement for your spam & virus filtering technology. If you >can't manage to realize the virus laden email should perhaps be >dropped, then it makes your box look poorly designed. > >Oh, and please delete the infected file rather than sending that along too. > >OK, off my soapbox. > >Dan > >
Re: Clueless anti-virus products/vendors (was Re: Sober)
On Friday 02 December 2005 14:27, Daniel Senie wrote: > Oh, and please delete the infected file rather than sending that along too. Here, Here Roughly 50 percent of the sober messages I have been getting hammered with are the basic "sorry we could not deliver your virus message, so here it is" - intact -- Larry Smith SysAd ECSIS.NET [EMAIL PROTECTED]
