qmail Digest 27 Jan 1999 11:00:17 -0000 Issue 533 Topics (messages 20945 through 20977): getpwnam() bug in freebsd-2.2.8 affects qmail 20945 by: "Paul J. Schinder" <[EMAIL PROTECTED]> Unable to run qmail-remote from resource exthaustion PERMENENT error? 20946 by: "Fred Lindberg" <[EMAIL PROTECTED]> 20963 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20975 by: Peter van Dijk <[EMAIL PROTECTED]> qmail-lint-0.50 20947 by: Peter Haworth <[EMAIL PROTECTED]> 20948 by: "Soffen, Matthew" <[EMAIL PROTECTED]> 20950 by: Russell Nelson <[EMAIL PROTECTED]> 20951 by: Matthias Pigulla <[EMAIL PROTECTED]> 20952 by: Russell Nelson <[EMAIL PROTECTED]> qmail-lint-0.51 20949 by: Russell Nelson <[EMAIL PROTECTED]> 20957 by: listy-dyskusyjne Krzysztof Dabrowski <[EMAIL PROTECTED]> Help Unsubscribing 20953 by: "Paul Coward" <[EMAIL PROTECTED]> Return-path header 20954 by: [EMAIL PROTECTED] 20955 by: Harald Hanche-Olsen <[EMAIL PROTECTED]> Mailbox size question 20956 by: Iain Hardcastle <[EMAIL PROTECTED]> 20958 by: "Scott D. Yelich" <[EMAIL PROTECTED]> how to reduce traffic on list... 20959 by: Roger Merchberger <[EMAIL PROTECTED]> 20960 by: Peter van Dijk <[EMAIL PROTECTED]> 20962 by: Stuart Young <[EMAIL PROTECTED]> Newbie configuration 20961 by: [EMAIL PROTECTED] Three solutions for spam 20964 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20965 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20966 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20967 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20968 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20969 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20970 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20971 by: "Paul J. Schinder" <[EMAIL PROTECTED]> 20972 by: Russell Nelson <[EMAIL PROTECTED]> 20973 by: "Rask Ingemann Lambertsen" <[EMAIL PROTECTED]> 20974 by: Chris Johnson <[EMAIL PROTECTED]> 20976 by: Peter van Dijk <[EMAIL PROTECTED]> 20977 by: Bo Fussing <[EMAIL PROTECTED]> Administrivia: To subscribe to the digest, e-mail: [EMAIL PROTECTED] To unsubscribe from the digest, e-mail: [EMAIL PROTECTED] To post to the list, e-mail: [EMAIL PROTECTED] ----------------------------------------------------------------------
At 1:16 AM -0500 1/26/99, Peter C. Norton wrote: } On Mon, Jan 25, 1999 at 08:24:00PM -0500, Paul J. Schinder wrote: } > At 8:18 PM -0500 1/25/99, Peter C. Norton wrote: } > } A moderated list would be a good thing. } > } > Moderated how? About all I can think of is that the FAQ's and complaint } > about "no multiple RCPT" could be removed. That doesn't strike me as all } > that much of the traffic, although I may just be fooling myself. } } The purpose is to create a list that would announce qmail } show-stoppers. Someone has to decide what's worth putting on the } list, or every week the list will get messages from someone with } weitse's qmail-smtpd DoS attack. That sort of message only needs to } be seen once, and then it can become part of a FAQ. OK, it wasn't clear what you had in mind. Dan already has an announce list <ftp://koobera.math.uic.edu/www/lists.html#qmailannounce>, and IIRC he subscribed everyone on the qmail list to it when he set it up, although I could be wrong. Is that the idea provided it get archived and the archive pointed to as "read this first"? } } -Peter --- Paul J. Schinder NASA Goddard Space Flight Center Code 693, Greenbelt, MD 20771 [EMAIL PROTECTED]
Testing ezmlm stuff on a 486/32MB I ran into some resource exhaustion, and noticed that qmail-remote crashing is a permanent error, while an inability to fork qmail-remote is a permanent error. This seems incorrect and caused loss of a message. Log (the second entry is a crash leading to the expected deferral): Jan 26 11:56:10 id qmail: 917351770.477256 status: local 0/10 remote 40/40 Jan 26 11:56:10 id qmail: 917351770.832994 delivery 7497: failure: Unable_to_run_qmail-remote./ Jan 26 11:56:11 id qmail: 917351771.243102 status: local 0/10 remote 39/40 [...] Jan 26 11:56:11 id qmail: 917351771.689201 status: local 0/10 remote 38/40 Jan 26 11:56:11 id qmail: 917351771.689736 delivery 7498: deferral: qmail-remote_crashed./ Jan 26 11:56:11 id qmail: 917351771.690242 status: local 0/10 remote 37/40 qmail-rspawn.c (qmail-1.03): if (wait_crashed(wstat)) { substdio_puts(ss,"Zqmail-remote crashed.\n"); return; } switch(wait_exitcode(wstat)) { case 0: break; case 111: substdio_puts(ss,"ZUnable to run qmail-remote.\n"); return; default: substdio_puts(ss,"DUnable to run qmail-remote.\n"); return; } IMHO, the default should be a Z... temporary error as well and specific errors captured to give a permanent error (i.e. 100). I assume that the error code here was something from the OS (Redhat Linux 5.1 x86). -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
On 26-Jan-99 16:06:07, Fred Lindberg wrote something about "Unable to run qmail-remote from resource exthaustion PERMENENT error?". I just couldn't help replying to it, thus: > Testing ezmlm stuff on a 486/32MB I ran into some resource exhaustion, > and noticed that qmail-remote crashing is a permanent error, while an > inability to fork qmail-remote is a permanent error. This seems > incorrect and caused loss of a message. > Log (the second entry is a crash leading to the expected deferral): > Jan 26 11:56:10 id qmail: 917351770.477256 status: local 0/10 remote > 40/40 > Jan 26 11:56:10 id qmail: 917351770.832994 delivery 7497: failure: > Unable_to_run_qmail-remote./ I saw the same thing today. Resource exhaustion (memory) leading to that error message and bounced mail. Not good at all. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | If you wake up Sleepy & Grumpy, you must be Snow White. |
On Tue, Jan 26, 1999 at 08:36:39PM +0100, Rask Ingemann Lambertsen wrote: > On 26-Jan-99 16:06:07, Fred Lindberg wrote something about "Unable to run >qmail-remote from resource exthaustion PERMENENT error?". I just couldn't help >replying to it, thus: > > Testing ezmlm stuff on a 486/32MB I ran into some resource exhaustion, > > and noticed that qmail-remote crashing is a permanent error, while an > > inability to fork qmail-remote is a permanent error. This seems > > incorrect and caused loss of a message. loss or bounce? > > Log (the second entry is a crash leading to the expected deferral): > > Jan 26 11:56:10 id qmail: 917351770.477256 status: local 0/10 remote > > 40/40 > > Jan 26 11:56:10 id qmail: 917351770.832994 delivery 7497: failure: > > Unable_to_run_qmail-remote./ > > I saw the same thing today. Resource exhaustion (memory) leading to that > error message and bounced mail. Not good at all. Greetz, Peter. -- .| Peter van Dijk .| [EMAIL PROTECTED]
> I've uploaded qmail-lint-0.50 to www.qmail.org. It checks for common > problems in your qmail control files. If you try it, and it prints > something you don't understand, or you think is not a problem, send me > email. Or if it misses a known problem, I'd also to hear about that > as well. Comments in control/locals are treated somewhat strangely. All lines are pushed onto @locals, but only those which aren't comments are added to %locals. Then comments matching /^#\s/ are treated differently to those which don't. I get: Warning: a host # Web server names in locals does not appear in rcpthosts. Warning: a host in locals does not appear in rcpthosts. ... where the first warning is for "# Web server names" and the second is for "#physicsweb.org" I don't understand the distinction between different types of comment, but this patch ignores comments completely anyway: *** qmail-lint-0.50 Tue Jan 26 13:45:48 1999 --- qmail-lint Tue Jan 26 16:05:30 1999 *************** *** 24,29 **** while(<F>) { chomp; - push(@locals,$_); next if m"^#"; $locals{$_} = ""; } --- 24,29 ---- while(<F>) { chomp; next if m"^#"; + push(@locals,$_); $locals{$_} = ""; } *************** *** 36,41 **** while(<F>) { chomp; - push(@virtualdomains,$_); next if m"^#"; if (split(/:/) < 2) { print "Warning: Line $. in control/virtualdomains has no colon:\n"; --- 36,41 ---- while(<F>) { chomp; next if m"^#"; + push(@virtualdomains,$_); if (split(/:/) < 2) { print "Warning: Line $. in control/virtualdomains has no colon:\n"; -- Peter Haworth [EMAIL PROTECTED] "The net serves four of the five physical senses. You can get sight, and sound, and to a limited extent tactile feedback. No one would deny that some portions of the net smell, but I see no signs that taste will ever come to the net." -- bill davidsen
If I am reading this correctly, it is only going to work for comments that are at the beginning of a line, not in the middle (or after the command in this case). Matt Soffen Webmaster - http://www.iso-ne.com/ ============================================== Boss - "My boss says we need some eunuch programmers." Dilbert - "I think he means UNIX and I already know UNIX." Boss - "Well, if the company nurse comes by, tell her I said never mind." - Dilbert - ============================================== > ---------- > From: Peter Haworth[SMTP:[EMAIL PROTECTED]] > Reply To: Peter Haworth > Sent: Tuesday, January 26, 1999 11:14 AM > To: Russell Nelson > Cc: [EMAIL PROTECTED] > Subject: Re: qmail-lint-0.50 > > > I've uploaded qmail-lint-0.50 to www.qmail.org. It checks for > common > > problems in your qmail control files. If you try it, and it prints > > something you don't understand, or you think is not a problem, send > me > > email. Or if it misses a known problem, I'd also to hear about that > > as well. > > Comments in control/locals are treated somewhat strangely. All lines > are pushed > onto @locals, but only those which aren't comments are added to > %locals. Then > comments matching /^#\s/ are treated differently to those which don't. > I get: > > Warning: a host # Web server names in locals does not appear in > rcpthosts. > Warning: a host in locals does not appear in rcpthosts. > > ... where the first warning is for "# Web server names" and the second > is for > "#physicsweb.org" > > I don't understand the distinction between different types of comment, > but this > patch ignores comments completely anyway: > *** qmail-lint-0.50 Tue Jan 26 13:45:48 1999 > --- qmail-lint Tue Jan 26 16:05:30 1999 > *************** > *** 24,29 **** > while(<F>) { > chomp; > - push(@locals,$_); > next if m"^#"; > $locals{$_} = ""; > } > --- 24,29 ---- > while(<F>) { > chomp; > next if m"^#"; > + push(@locals,$_); > $locals{$_} = ""; > } > *************** > *** 36,41 **** > while(<F>) { > chomp; > - push(@virtualdomains,$_); > next if m"^#"; > if (split(/:/) < 2) { > print "Warning: Line $. in control/virtualdomains has no > colon:\n"; > --- 36,41 ---- > while(<F>) { > chomp; > next if m"^#"; > + push(@virtualdomains,$_); > if (split(/:/) < 2) { > print "Warning: Line $. in control/virtualdomains has no > colon:\n"; > > > > > > -- > Peter Haworth [EMAIL PROTECTED] > "The net serves four of the five physical senses. You can get sight, > and > sound, and to a limited extent tactile feedback. No one would deny > that > some portions of the net smell, but I see no signs that taste will > ever > come to the net." -- bill davidsen >
Soffen, Matthew writes: > If I am reading this correctly, it is only going to work for comments > that are at the beginning of a line, not in the middle (or after the > command in this case). That's how control.c:control_readfile() works: if (line.s[0]) if (line.s[0] != '#') if (!stralloc_cat(sa,&line)) break; -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Russell Nelson wrote: > That's how control.c:control_readfile() works: > if (line.s[0]) > if (line.s[0] != '#') > if (!stralloc_cat(sa,&line)) break; Right now, it drops all lines starting with a #, so, as far as I can see, it is not affected of the problem that had to be patched in qmail-lint, right? Well, shouldn't the snippet above be modified to discard the rest of a line if a '#' sign is found (so, # declares a comment, no matter where it's located)? I'm curious about this, for I am currently writing a tool to spawn mail to a list of recipients retrieved from a MySQL database. I was just looking into control.c to find out what exactly control_readfile does, as this mail came in ;-) Matthias -- w e b f a c t o r y | matthias pigulla www.webfactory.de [EMAIL PROTECTED]
Matthias Pigulla writes: > Russell Nelson wrote: > > That's how control.c:control_readfile() works: > > if (line.s[0]) > > if (line.s[0] != '#') > > if (!stralloc_cat(sa,&line)) break; > > Right now, it drops all lines starting with a #, so, as far as I can > see, it is not affected of the problem that had to be patched in > qmail-lint, right? Vice-versa. It was qmail-lint which wasn't doing the same thing as control_readfile(). > Well, shouldn't the snippet above be modified to discard the rest of a > line if a '#' sign is found (so, # declares a comment, no matter where > it's located)? Well, maybe, but that's not what it does do. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Peter Haworth writes: > > I've uploaded qmail-lint-0.50 to www.qmail.org. It checks for common > > problems in your qmail control files. If you try it, and it prints > > something you don't understand, or you think is not a problem, send me > > email. Or if it misses a known problem, I'd also to hear about that > > as well. > > Comments in control/locals are treated somewhat strangely. All lines are pushed > onto @locals, but only those which aren't comments are added to %locals. Then > comments matching /^#\s/ are treated differently to those which don't. Um, yes. Same thing for virtualdomains, both fixed: I've uploaded qmail-lint-0.51 to www.qmail.org. It now has a -v flag which prints a more verbose explanation of why something might be a problem. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
If you like some suggetsions then you can make a switch that will prevent your script from checking in a local or virtualdomain is in rcpthosts. We are using RELAYCLIENT in tcpserver so rcpthosts are not neede and your script is making too much noise. Not that i can't grep it out but you can make it as a feature if you like. All in all nice program and i hope it'll evolve.. Kris
Hi, Could someone please give me the address to ausubscribe from this list, I've lost it. Thanks. Cheers Paul Coward System Administrator http://www.asgard.net.au ph: +61-(0)7-32773255 fax: +61-(0)7-32778473
I don't seem to be getting a return-path header added to messages coming in over the net. Most qmail users I've talked to seem to expect this, and there seems to be code in qmail-local to add it at least under some conditions. I'm back on qmail 1.02, not 1.03 yet. And I've received email from one other qmail user saying their system also isn't providing a return-path header. Anybody have any ideas? (I've been successfully running qmail, in various versions, for years, and handling mailing lists and such; it's not a new installation). -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
- [EMAIL PROTECTED]: | I don't seem to be getting a return-path header added to messages | coming in over the net. It is added on maildir and mailbox delivery. When delivering to a program, it is not added automatically, but is available in an environment variable ($RPLINE) for the program to use if it so wishes. When forwarding, it is (of course) not added, but the envelope sender is preserved, so it can be duly noted on final delivery. If you find any departures from these rules, let us know the details. - Harald
People, In doing some consulting work for an ISP, I need to specify a mail server. Could all you ISP techs please respond with a good figure for sizing a mail account? I mean if you are going to offer mail, on average, how much would you allocate per client when sizing a machine to run it. Also, does q-mail offer features for limiting mail stored on a mailhost? Regards Iain.
> Could all you ISP techs please respond with a good figure for sizing a > mail account? I mean if you are going to offer mail, on average, how > much would you allocate per client when sizing a machine to run it. > Also, does q-mail offer features for limiting mail stored on a mailhost? You could run quotas on the home directory in conjunction with a $HOME/Maildir delivery. Here's the output from one ISP in bytes, your mileage may vary: 981 mailboxes, sum is 371273489 average is 377310 Scott
Once upon a midnight dreary, Paul J. Schinder had spoken clearly: >At 8:18 PM -0500 1/25/99, Peter C. Norton wrote: >} A moderated list would be a good thing. > >Moderated how? About all I can think of is that the FAQ's and complaint >about "no multiple RCPT" could be removed. That doesn't strike me as all >that much of the traffic, although I may just be fooling myself. > >I agree this is getting to be a high volume list, but I think the better >solution to high volume lists is a Usenet newsgroup, where a newsreaders >filters can be brought to bear. Maybe it's finally time to start the >process? I was on a SunOS/Solaris admin mailing list, and how they worked it was like this: You posted your original question to the list, everyone who wished to reply replied to the *sender*, not the list, Then the original poster posted a summary of the help he received back to the list, with SUMMARY: ... as the beginning of the subject. Anyone else think something like this might work here??? Just my $0.0000002, Roger "Merch" Merchberger -- Roger "Merch" Merchberger --- sysadmin, Iceberg Computers Recycling is good, right??? Ok, so I'll recycle an old .sig. If at first you don't succeed, nuclear warhead disarmament should *not* be your first career choice.
On Tue, Jan 26, 1999 at 06:54:40PM -0500, Roger Merchberger wrote: > Once upon a midnight dreary, Paul J. Schinder had spoken clearly: > >At 8:18 PM -0500 1/25/99, Peter C. Norton wrote: > > >} A moderated list would be a good thing. > > > >Moderated how? About all I can think of is that the FAQ's and complaint > >about "no multiple RCPT" could be removed. That doesn't strike me as all > >that much of the traffic, although I may just be fooling myself. > > > >I agree this is getting to be a high volume list, but I think the better > >solution to high volume lists is a Usenet newsgroup, where a newsreaders > >filters can be brought to bear. Maybe it's finally time to start the > >process? > > I was on a SunOS/Solaris admin mailing list, and how they worked it was > like this: > > You posted your original question to the list, > everyone who wished to reply replied to the *sender*, not the list, > Then the original poster posted a summary of the help he received back to > the list, with SUMMARY: ... as the beginning of the subject. > > Anyone else think something like this might work here??? That'll take the fire out of most discussions. Stuff like that works for lists like BUGTRAQ, where stuff is usually either true or untrue. But on this list, things are really _discussed_. Take for example the spam thread. Or the RedHat thread. I LOVED those threads. No, it wouldn't work. Usually. When somebody has a concrete problem, yes, it might work. But when really discussing stuff, no. So, don't make this thing moderated. Greetz, Peter. -- .| Peter van Dijk .| [EMAIL PROTECTED]
At 00:54 27/01/99 +0100, Peter van Dijk wrote: >That'll take the fire out of most discussions. Stuff like that works for >lists like BUGTRAQ, where stuff is usually either true or untrue. But >on this list, things are really _discussed_. Take for example the spam >thread. Or the RedHat thread. I LOVED those threads. > >No, it wouldn't work. Usually. When somebody has a concrete problem, yes, >it might work. But when really discussing stuff, no. So, don't make this >thing moderated. Absolutely spot on, however, there are a lot of common problems, misconceptions, and errors that people make that are not covered on the FAQ, or on the www.qmail.org page. The www.qmail.org page is just too large as one single page. It needs to be broken up into sections, and possibly those sections into sections. Russ HAS done a good job on it, but it's sort of swelled a bit. Too much information on one page tends to boggle people more than help them. Mebbe a section that describes some of the more common things, like ETRN, and then points you at the appropiate page to find out how to implement it, or alternatively, do the same thing a different way (AutoTURN), making the whole thing a learning resource. We also need to suppliment the FAQ, as while it's good, it does lack a few things. Pointing out how to use tcpserver instead of inetd (and mentioning that tcpserver is better for this case) for qmail and it's associated utils is great, but a lot of people will use other utilities, and details on how to do it should be kept somewhere. Mebbe a CGI script where a few maintainers can quickly add things to a central resource? Certinaly make updating the FAQ et al much easier having that information on hand at a later date. Anyway, enuff of my clap-trap. Time for someone else to comment. Stuart Young - [EMAIL PROTECTED] - [EMAIL PROTECTED] (aka Cefiar) - http://amarok.glasswings.com.au/ [All opinions expressed in the above message are my] [own and not necessarily the views of my employer..]
I'm quite new to Linux, and very new to setting up mail so please bear with me if these are stupid questions. I've got a one user dial-up box, retrieving mail from my provider using fetchmail. I'm pretty sure I'm not doing this the right way. I've got two files in control/ me: mymadeupdomainname.com virtualdomains: [EMAIL PROTECTED]:trent trent@localhost:trent :alias-outgoing_ppp This is they only setup that I can get to work. If I take out the trent@localhost line mail gets put in the outgoing_ppp dir (where my mail is queued until I connect) when I run fetchmail. I know there is rcpthosts, locals, ... but I don't know how to set them up. If someone can tell me the correct way to configure this I would be grateful.
On 17-Jan-99 04:49:03, Russell Nelson wrote something about "Three solutions for spam". I just couldn't help replying to it, thus: > Most spam comes from one of three sources: > 1) spamhauses. The RBL blocks these. MAPS RBL. > 2) open relays. ORBS RBL (which I'm happy to see has returned). > 3) dialups. DUL RBL. Actually, I'm not too happy about blocking dialups in general since these people haven't done anything wrong. I'd be much happier if Internet providers would put their trial users into a separate subnet, which could then be blocked, without affecting honest dialup users. > Consult the DNS to see if the host has a name. Reject the mail if it > doesn't. Probably a good idea, but > Consult the DNS to see if the host's name has > an MX record. If it doesn't, reject the mail. ??? > The downside of these fixes are that they carry a lot of collateral > damage. The latter one of you suggestions surely will. You'd be lucky to get any mail at all. Assuming that (heaven forbid) this was actually widely deployed, exactly what would you have achieved, except for 4 billion extra MX records to stress test the DNS? Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | It's bad luck to be superstitious. |
On 18-Jan-99 15:55:12, Russell Nelson wrote something about "Re: Three solutions for spam". I just couldn't help replying to it, thus: > Len Budney writes: > > It was quite standard at each company to send email direct through > > dialup, w/valid return address of company email, to save phone costs > > and company bandwidth. > > > > Are you suggesting there is something wrong with this? > Sure. It's a false economy. What if the mail doesn't go through? > What if the destination host blocks mail from dialups? Bah. What if your relay host drops the message for some reason? The fewer hops a message takes, the more likely it is to make it through to the recipient(s). Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | If a train station is where a train stops, what is a workstation then? |
On 17-Jan-99 16:24:16, Russell Nelson wrote something about "RE: Three solutions for spam". I just couldn't help replying to it, thus: > Stefaan A Eeckels writes: > > I'm not a spammer. I've got my machine on a dial-up using > > a dynamic IP address. This anti-SPAM measure forces me to > > go through a smarthost, which (with qmail) gives no real > > advantages, and reduces the control I have over the delivery > > process. I find such a blanket rule offensive. > I find spam offensive. All other forms of spam control exact a price; > why do you expect this one to be free? If it comes down to it, > Stefaan, I'll let you relay off my host. Most other anti-spam measures have a technical foundation. Invalid domain, header field syntax error, no or incorrect reverse DNS, etc. Blocking dialups doesn't. IMHO, it comes dangerously close to racism. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | Never underestimate the bandwidth of a CD-ROM flying through the lab. |
On 18-Jan-99 05:51:16, Chris Johnson wrote something about "Re: Three solutions for spam". I just couldn't help replying to it, thus: > I've always wondered why Dan doesn't have an MX record for koobera (though > it doesn't really matter now that we're supposed to be using list.cr.yp.to). > An A record is all that's required to get the mail delivered, but if there > were an MX record my name server would cache it, rather than making a query > in vain for a non-existent MX record every time a message needs to go there. There is such a thing as caching of negative replies. Correct me if I'm wrong, but IIRC, BIND does so. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | That was a pointing device? My cat thought it was dinner. |
On 18-Jan-99 13:30:02, Pedro Melo wrote something about "Re: Three solutions for spam". I just couldn't help replying to it, thus: > One ideia is to send the open-relay's found to RBL. After they show up in > RBL, remove them from your local list. > Does RBL has a automatic procedure to test open relays? The ORBS (Open Relay Blocking System) RBL is what you're looking for. <URL:http://www.orbs.org/>. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | Es funktioniert nicht, sieht aber gut aus. |
On 20-Jan-99 01:05:32, Russ Allbery wrote something about "Re: Three solutions for spam". I just couldn't help replying to it, thus: > Racer X <[EMAIL PROTECTED]> writes: >> The 1% that do care can either be provided with the service they need or >> (usually) talked out of it by simply explaining the nature of the >> service they're looking for. Some people have concerns for privacy but >> fail to realize that merely avoiding our mail server wouldn't keep us >> from snooping anyway. Others run Linux or something with sendmail and >> just don't know how to set up their machine properly. It's worth an >> hour of my time to keep a customer happy and educate them on how to >> better run their system. > Like I said. And there are a few people who just want to be in control of > their own mail. I know I would. I know lots of other people feel the > same way. You may be a great, well-run, reliable outfit, but the fact > remains that computers fail and things go wrong, often at the *remote* > side, and unless you're running your own outgoing mail, finding out about > it is a crap shoot. I agree. Just from running a 150 subscriber mailing list, I've seen enough bounces caused by malfunctioning or weirdly misconfigured mail systems that I wouldn't trust an ISP to be able to handle my email. And when spammers start using the ISP's relay to send out their junk, and the ISP's relay is subsequently blocked, you'll be glad that you can do the deliveries from your own box. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | Machine-independent: Does not run on any existing machine. |
On 22-Jan-99 11:45:54, Russ Allbery wrote something about "Re: Three solutions for spam". I just couldn't help replying to it, thus: > Racer X <[EMAIL PROTECTED]> writes: >> Spam filtering may well result in the loss of legitimate email. >> Blocking outbound SMTP connections will not, as the mail will never be >> sent in the first place. > But blocking outbound SMTP connections doesn't seem to serve much purpose > unless you also do spam filtering, or am I missing something? Is there a > practical difference between letting customers spam directly and letting > customers spam through your mail relay apart from the utility of having a > choke point where you can track and cut them off? Not as far as I can tell. If it really is that easy to block ports on an individual user basis, you can just as easily block them at your router as you can at your mail system. Or perhaps it is even easier to do at the router than at the mail system. As for monitoring, you can also just monitor their port 25 activity instead of couting the number of messages they have queued at your relay. Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | I'm as confused as a baby at a topless bar! |
On Tue, Jan 26, 1999 at 11:21:33PM +0100, Rask Ingemann Lambertsen wrote: } } The ORBS (Open Relay Blocking System) RBL is what you're looking for. } <URL:http://www.orbs.org/>. Is that actually up yet? relays.orbs.org has never resolved for me. } } Regards, } } | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | } | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | } | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | } | Es funktioniert nicht, sieht aber gut aus. | } -- Paul J. Schinder NASA Goddard Space Flight Center [EMAIL PROTECTED]
Rask Ingemann Lambertsen writes: > Most other anti-spam measures have a technical foundation. Invalid domain, > header field syntax error, no or incorrect reverse DNS, etc. Blocking dialups > doesn't. IMHO, it comes dangerously close to racism. The term is "prejudice", not racism. Race isn't a factor here. And it's a reasonable prejudice, since all of the non-relayed spam I get comes from dialups. Not all prejudice is bad. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
On 27-Jan-99 05:40:24, Paul J. Schinder wrote something about "Re: Three solutions for spam". I just couldn't help replying to it, thus: > On Tue, Jan 26, 1999 at 11:21:33PM +0100, Rask Ingemann Lambertsen wrote: > } > } The ORBS (Open Relay Blocking System) RBL is what you're looking for. > } <URL:http://www.orbs.org/>. > Is that actually up yet? relays.orbs.org has never resolved for me. Works fine here: 23. Cache:> nslookup -query=txt 2.0.0.127.relays.orbs.org Server: carlsberg.kampsax.dtu.dk Address: 192.38.212.2 Non-authoritative answer: 2.0.0.127.relays.orbs.org text = "The server sending this mail is listed by ORBS. See http://www.orbs.org/ for more information." Authoritative answers can be found from: relays.orbs.org nameserver = skynet.simkin.com relays.orbs.org nameserver = doubtful.cynic.net relays.orbs.org nameserver = ns1.innotts.co.uk relays.orbs.org nameserver = ns3.manawatu.net.nz relays.orbs.org nameserver = ns4.manawatu.net.nz skynet.simkin.com internet address = 199.175.137.111 doubtful.cynic.net internet address = 207.6.128.246 ns1.innotts.co.uk internet address = 195.89.181.6 ns3.manawatu.net.nz internet address = 209.74.170.190 ns4.manawatu.net.nz internet address = 209.242.93.190 Regards, /ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | If a train station is where a train stops, what is a workstation then? |
On Tue, Jan 26, 1999 at 11:19:32PM +0100, Rask Ingemann Lambertsen wrote: > On 18-Jan-99 05:51:16, Chris Johnson wrote something about "Re: Three solutions for >spam". I just couldn't help replying to it, thus: > > > I've always wondered why Dan doesn't have an MX record for koobera (though > > it doesn't really matter now that we're supposed to be using list.cr.yp.to). > > An A record is all that's required to get the mail delivered, but if there > > were an MX record my name server would cache it, rather than making a query > > in vain for a non-existent MX record every time a message needs to go there. > > There is such a thing as caching of negative replies. Correct me if I'm > wrong, but IIRC, BIND does so. I think recent versions of BIND do cache negative replies, but only for a very short time. I don't have any documentation handy, but I think it's only for ten minutes. So having an MX record, even if you already have an A record, would cut down on name server queries. Chris
On Wed, Jan 27, 1999 at 12:26:35AM -0500, Chris Johnson wrote: > On Tue, Jan 26, 1999 at 11:19:32PM +0100, Rask Ingemann Lambertsen wrote: > > On 18-Jan-99 05:51:16, Chris Johnson wrote something about "Re: Three solutions >for spam". I just couldn't help replying to it, thus: > > > > > I've always wondered why Dan doesn't have an MX record for koobera (though > > > it doesn't really matter now that we're supposed to be using list.cr.yp.to). > > > An A record is all that's required to get the mail delivered, but if there > > > were an MX record my name server would cache it, rather than making a query > > > in vain for a non-existent MX record every time a message needs to go there. > > > > There is such a thing as caching of negative replies. Correct me if I'm > > wrong, but IIRC, BIND does so. > > I think recent versions of BIND do cache negative replies, but only for a very > short time. I don't have any documentation handy, but I think it's only for ten > minutes. So having an MX record, even if you already have an A record, would > cut down on name server queries. Well, I've been discussing this very subject (negative caching) with some friends very deeply after the .nl domain-registry decided to f*ck things up badly. BIND caches negative (authorative) replies for 10 minutes, indeed. Greetz, Peter. -- .| Peter van Dijk .| [EMAIL PROTECTED]
> Rask Ingemann Lambertsen writes: > > Most other anti-spam measures have a technical foundation. Invalid domain, > > header field syntax error, no or incorrect reverse DNS, etc. Blocking dialups > > doesn't. IMHO, it comes dangerously close to racism. > > The term is "prejudice", not racism. Race isn't a factor here. And > it's a reasonable prejudice, since all of the non-relayed spam I get > comes from dialups. Not all prejudice is bad. I agree 100% with Russel, here in Hong Kong the HK ISP Association is about to begin an innitiative for our members to block outgoing port 25 connections from modem pools. As for the prejudice against users - I think this is a non-issue since people accessing the Internet have absolutely no need to use third party mail relays. If they don't trust our systems (all qmail!) then they are free to go elsewhere. Considering the amount of Hong Kong generated SPAM (most of it from dial-up users) that we might be able to eliminate I hope we can implement this scheme soon. Bo ----------------------------------------------------------------- Bo Fussing <[EMAIL PROTECTED]> Gateway Internet Ltd. <Hong Kong> Tel +852 2963-7173 Fax +852 2963-7353 URL http://www.gateway.net.hk PGP fingerprint = D7 9F ED 1D E5 B9 62 4F 77 BC D1 33 5B 4E 95 81 For PGP ID & Signature mail empty message to [EMAIL PROTECTED]