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]
