- Test - lists.nanog.org

RE: handling Sircam and the like from the e-mail service operator 's perspective...
by Roeland Meyer 03 Aug '01

03 Aug '01

> -----Original Message----- > From: woods(a)weird.com [mailto:woods@weird.com] > Sent: Friday, August 03, 2001 9:32 AM > I'm beginning to find that some of my clients who operate e-mail > services are facing some very real ongoing operational issues with the > likes of the Sircam worm/Trojan. At the moment the clients with the > most pressing problem is a small cable-modem and dial-up operator. > > So far I've been advising all of my clients to treat these kinds of > worms as valid e-mail and to simply help their end users, where > possible, to eliminate it and deal with its impacts. I.e. if we're > going to accept any e-mail from a given SMTP client to a > given recipient > then we accept it and deliver it without regard to its content. That last part is the problem. Why not filter on SirCam, at the mail host? We had to do the LoveBug and it worked well. The issues were almost identical, except that LoveBug was smaller. > We're working under the general assumption that a large > segment of these > users would undoubtably become very angry if we simply > filtered out all > attachments, or even just those with filename extensions that losing > software might try to "execute" (though in general that means anything > that might include "macros" with the data too!), however I > don't see any > other manageable way to stop this kind of attack (other than > eliminating > or fixing all of the broken software that can be exploited in > this way!). Run virus scanners on all inbound mail. Yes, I know that burns CPU cycles like mad. It does a pretty good job of thrashing DASD as well. > We're also working under the general assumption that a large > segment of > these users would become very angry if we dropped the maximum message > size to a limit that at least Sircam and its ilk couldn't quickly > overflow our average mailbox quotas. We've done this temporarily > overnight and over weekends before we upgraded system capacities, and > that did cause a lot of extra load on the support lines, but > it stopped > transmission of at least Sircam in its tracks (being it's > always >135KB). > My clients will generally be able to manage the expectations of their > users better if they can point to other larger service > providers who've > taken equally, or more, draconian measures.... :-) Since you have a working signature, for SirCam, why not use it in production?

1 0

Need Fast E drop @ 60 Hudson St NY
by doug healy 03 Aug '01

03 Aug '01

We are looking for a Fast Ethernet drop at 60 Hudson St NY. Please feel free to respond in private Email Thanks Doug Healy Streampipe Inc doug(a)streampipe.com

1 0

Re: trapdoor.merit.edu and other impatient Postfix mailers everywhere (fwd)
by Larry Sheldon 03 Aug '01

03 Aug '01

> It is interesting to see some of the sites that not only use(d) the MAPS > lists for free, but didn't even bother to do the zone transfer mode > (which reduces the load on the MAPS servers and speeds up your local > use). At least one of us thinks the zone transfer mode was not free; and, at least one of us thinks the sendmail configuration we were using was taken from the vix.com site as is. At least one of us has a reputation for being wrong from time to time.

22 36

handling Sircam and the like from the e-mail service operator's perspective...
by woods＠weird.com 03 Aug '01

03 Aug '01

I'm beginning to find that some of my clients who operate e-mail services are facing some very real ongoing operational issues with the likes of the Sircam worm/Trojan. At the moment the clients with the most pressing problem is a small cable-modem and dial-up operator. So far I've been advising all of my clients to treat these kinds of worms as valid e-mail and to simply help their end users, where possible, to eliminate it and deal with its impacts. I.e. if we're going to accept any e-mail from a given SMTP client to a given recipient then we accept it and deliver it without regard to its content. Now that we've ironed out tuning and configuration issues so that our systems can actually handle the increased SMTP load, especially that caused by Sircam in particular, we're finding that our users simply can't handle the load. There are far more users with constantly over-quota mailboxes (Sircam being particularly evil at sending large files). This is just as effective a denial of service for those users as any failure in the SMTP transport or mailbox access protocols would be. The users can still retrieve what e-mail they receive just fine, even most of the dial-up users, but there's so much of it now that most users, especially home users, don't keep up with the flow. Last night alone (eg. over an ~12hr period) we had over 1000 copies of the Sircam worm itself (with attached files, of course) dumped into the error queue because both the sender's and the recipient's mailboxes were over quota (and of course not all the senders were local either). I've given up counting the number of copies that have likely been delivered -- it's just way too many to comprehend. We're working under the general assumption that a large segment of these users would undoubtably become very angry if we simply filtered out all attachments, or even just those with filename extensions that losing software might try to "execute" (though in general that means anything that might include "macros" with the data too!), however I don't see any other manageable way to stop this kind of attack (other than eliminating or fixing all of the broken software that can be exploited in this way!). We're also working under the general assumption that a large segment of these users would become very angry if we dropped the maximum message size to a limit that at least Sircam and its ilk couldn't quickly overflow our average mailbox quotas. We've done this temporarily overnight and over weekends before we upgraded system capacities, and that did cause a lot of extra load on the support lines, but it stopped transmission of at least Sircam in its tracks (being it's always >135KB). How many of you who are also operators of e-mail services including mailboxes have implemented (for your customer mailboxes) such draconian indiscriminate attachment filters; and/or lowered your maximum allowed message size to something that would once upon a time have been considered overly generous, such as 100-150KB or so? How many of you have implemented more selective signature-based filtering, and of you how many are paying some (hopefully respected and trusted) third party to access regular updates of the signature list? How many of you consider signature based filtering to be bogus even though it would mostly mitigate the ongoing after-effects of something nasty like Sircam? How many of you have implemented per-mailbox restrictions so that end users must choose for themselves whether or not they'll ignore/drop/reject some of their e-mail? Please respond with any basic yes/no answers directly to me (if you can! ;-), and I'll post a followup summary by Tuesday or so if there's anything significant. My clients will generally be able to manage the expectations of their users better if they can point to other larger service providers who've taken equally, or more, draconian measures.... :-) ("I'm too scared to jump! Why don't the big boys jump first?" ;-) I've seen some de-fanged copies of Sircam that still matched my primitive signature check from Yahoo.... -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0

RE: trapdoor.merit.edu and other impatient Postfix mailers everyw here (fwd)
by Roeland Meyer 03 Aug '01

03 Aug '01

> From: Steven J. Sobol [mailto:sjsobol@NorthShoreTechnologies.net] > Sent: Thursday, August 02, 2001 5:31 PM > > On Thu, 2 Aug 2001, Matt Martini wrote: > > > I never liked the idea of someone else, with an agenda that I'm sure > > doesn't coinside with mine, telling me who I should talk to > > or not. When > > the source code defaulted to using these "services" that's > > when I bailed on sendmail. > > No one forces people to use the dnsbl feature, nor are they > forced to use > the default settings. dnsbl is turned off by default. Give me a break. > > I can't believe I'm hearing the crap I'm hearing from people > who should know better. Agreed. For the record, when I was still using sendmail, I had to build a new sendmail.cf on every install. The default, from Caldera, doesn't do RBL by default, or a lot of anything else. I am now using MS-Exchange for corporate groupware and am deploying Postfix for end-user usage. Since MAPS is no longer freeware (a fact that I do NOT begrudge them), I will no longer be using the RBL. It was of limited use anyway because, I have way too many Earthlink based users and Earthlink seems to have taken up permanent residency in the RBL <sigh>.

1 0

Re: trapdoor.merit.edu and other impatient Postfix mailers everywhere (fwd)
by Mathias Koerber 03 Aug '01

03 Aug '01

|> Sure. But you claim to have proof (in the two links you posted) that |> that feature was implemented on request of PV. That is not true, |> those links only refer to PV having requested that sendmail not |> relay. | |The claim was made that Paul Vixie had enough clout to influence |modifications to sendmail features according to his wishes, and have |someone write a best practices RFC intended to modify vendor behavior. |He was, after all, the daddy of the RBL. You seem to claim his server |rbl.maps.vix.com was perhaps referenced in the source against his will. I claim nothing of that sort. I was not talking about the RBL function at all. I was pointing out that the links you posted with 'proof' do not prove your claim that PV influenced the RBL feature in sendmail. Your links only prove that he was asking for sendmail to stop relaying, a *totally different* feature which has nothing to do with RBL or any other external blacklist!! How you can contrue from that that I claim anything about the RBL feature is not apparent. I do quite think he was possibly quite happy that it was referenced in the default dnsbl config. But that is a long way from having actually influenced that fact. I believe that whoever wrote the original rbl feature (and no, I do not know who wrote that!) used the MAPS server reference because it was available. |There's much more on the subject, but for the sake of this argument, |you win: it was miraculously introduced by the elves! Having not claimed anything about how rbl or dnsrbl got introduced I am puzzled why you want to concede to me on this point. methinks you could use some time off

1 0

Re: trapdoor.merit.edu and other impatient Postfix mailers everywhere (fwd)
by Mathias Koerber 03 Aug '01

03 Aug '01

|On Fri, 3 Aug 2001, Mathias Koerber wrote: | |> | |> |http://www.dotcomeon.com/relay_default.html |> |http://www.dotcomeon.com/allman_sendmail_qa.html |> |> |> These sources say that 'not relaying by default' was implemented |> on suggestion by Paul Vixie. They do not talk about checking MAPS |> (feature('dnsbl')) at all. | |And how, may I ask then, is the MAPS RSS implemented? By which |mechanism, and whose default server was specified? 'Not relaying' is totally unrelated to checking MAPS or any other RBL. It refers to the mailer not to relay mail from an outside address to another outside address not served by the mailer. There is no need to check any RBL for that. |Historically, the first feature was called (rbl), now superceded |by (dnsbl), and was introduced in sendmail rel. 8.9.1 (1998). Sure. But you claim to have proof (in the two links you posted) that that feature was implemented on request of PV. That is not true, those links only refer to PV having requested that sendmail not relay. | |> |Don't believe me. [...] |> |> I won't. Not after this. | |Okay then, perhaps you can come up with evidence to the contrary. You are making the claims, so it is upto you to provide proof. |BTW Mathias, we did have a few users from Singapore. They were |trying to avoid their country's strict censorship, and were relaying |their private correspondence through our server, although they had |accounts there. I wonder why? Perhaps it was the fear of rattan |canes that made them do it... Nice ad-natiomen :-) That has nothing to do with the topic at hand. Trying to deflect from unproven claims and apparent inability to prove them?

2 1

Re: trapdoor.merit.edu and other impatient Postfix mailers everywhere (fwd)
by Mathias Koerber 03 Aug '01

03 Aug '01

| |http://www.dotcomeon.com/relay_default.html |http://www.dotcomeon.com/allman_sendmail_qa.html These sources say that 'not relaying by default' was implemented on suggestion by Paul Vixie. They do not talk about checking MAPS (feature('dnsbl')) at all. |Don't believe me. [...] I won't. Not after this.

2 1

Re: MAPS changes
by Larry Sheldon 03 Aug '01

03 Aug '01

Ok, let's put a cork in it--we have more important things to do. Here is my final puclic say on the matter--I'll answer specific questions in private email, if I've made grievous error I'll acknowledge it here. > > We are sort of minimalist when it comes to modifying mainstream code, so > > I betting we got it of the box and plugged it. But that would have been > > on my watch, and I don't remember for sure. > > You have to build a configuration file for sendmail, and there are no > defaults that work out of the box. When I built my config file, I went > through the documentation saying "yes, I will take that feature, and that > one, ..." and one of them was the DNS RBL interface. In another message > you mention that you use HP's sendmail so I have no idea how that process > works, but I rarely use any vendor's shipping version of important code > like BIND, sendmail, ssh, etc as they are almost always out of date. Seems like I've already answered this somewhere--briefly, this is wrong. By the time I get through doing a cold install-plus-patches to H-PUX 11.0, BIND, Sendmail and so forth are up, up-to-date, and running. I'll remind (or inform) y'all that this is actually the second time this calendar year that MAPS did this. We found out quite by accident that the vix.com servers (which are in the H-PUX distribution) were about to be shut down. Then a month or two later, seems likem, they did the exact same thing again except this time in order to play we have to (in the first week of the new fiscal year) go hat-in-hand to beg for money to keep going. (Yes, I know, they have since said something about "free" if we sign some kind of contract. I'd rather beg for money, than get such a contract signed in my lifetime.) Let's go back to work.

1 0

MAPS changes (was RE: trapdoor.merit.edu and other...etc)
by Larry Sheldon 03 Aug '01

03 Aug '01

> Yes, you can lookup contact information for IP blocks. However, we all > know how up-to-date that is, and the person listed there may or may not > be involved with the mail server. The spammers seem to think its OK. Seems like anti-spammers could give it a try. > If there had been a notice here, would you have been as unhappy? Remember > this was a free service. If I decided I could no longer make chess endgame > databases available for free, I would not feel inclined to look up everyone > who had been using them and notify them. At first cut, I could not agree more. But at second and third thought when I realized that just yanking the thing would have, you might say, unanticipated consequences, I would try to find a way of (think of imploding a building) firing the trigger without having it fall in on me. > As I recall, the first modifications to use RBL in sendmail were done > elsewhere, eventually a link was included on the sendmail site, and then > it was part of the configuration. We are sort of minimalist when it comes to modifying mainstream code, so I betting we got it of the box and plugged it. But that would have been on my watch, and I don't remember for sure. > I can see you are bitter about the impact on your mailservers. I am not > happy about the way it was done as well, but assuming it was malacious > seems excessive. I don't think bitter is right--and I did in fact get wind of this in the anti-spam community several weeks ago so we had actually pulled the code out last week, I think. I'm just really tired of the cult-of-personality stuff. Lots of us are just trying to keep our tiny corner of the world running for reasons that do not glorify bits and bit-fiddlers against a growing tide of bad guys. Having trouble telling who is on your side and who isn't does not enhance the experience. And if I can figure out what IP addresses to block, I will try to ensure that we are not now part of their problem--self imposed it might be.

2 1