headers
Gerardo Arnaez | 1 Jun 2003 03:44
Picon
Favicon

test


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
Permalink | Reply | 0 comments |
headers
Russell Nelson | 1 Jun 2003 03:31
Favicon

errno autoresponder

Hi.  I now have an autoresponder which sends people email if they say
"errno" on the qmail mailing list.  Assuming it works (and I guess
I'll find out!), there's no need to respond to people who say
"errno".  If they just say "I can't build qmail on Red Hat 9", well,
it's just a grep, it's not artificial intelligence.

--

-- 
--My blog is at angry-economist.russnelson.com  | Rebecca's incredibly neat
Crynwr sells support for free software  | PGPok | County Fair quilt is now
521 Pleasant Valley Rd. | +1 315 268 1925 voice | at http://rebeccanelson.com/
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | quilt/index.html
Permalink | Reply | 1 comment |
headers
Chris Wilkes | 1 Jun 2003 03:55

Re: building qmail-1.03

On Sat, May 31, 2003 at 10:50:15PM +0200, Henning Brauer wrote:
> 
> > Otherwise, search the archives and with Google for your error message.
> > If you don't find a solution, post back here.  Many list members run
> > qmail on OpenBSD, so it does work, but it may need a patch.
> 
> no, stock qmail works fine.

As long as we're guessing what the error was, could the error be perhaps
occur when running qmail with a nosuid mounted /var?  Granted that
doesn't show up at compile time.

Chris
Permalink | Reply | 2 comments |
headers
Jeff Lasman | 1 Jun 2003 04:41

Re: Help please - new attack on an old problem

Jason Parsons wrote:

> Is mail being delivered at all?

Yes, at least some, and with a delay of up to 1/2 hour or so.

> > May 29 22:37:44 ns1 qmail: 1054273064.808214 warning: unable to open
> > todo/11/106271
> 
> Your queue is broken.  Did you install the big-todo patch, but not
> create the queue to match?  You should have run 'make setup check' from
> the source directory that you used to install qmail.

I didn't do anything <frown>; it's a Plesk 5.0.5 installation.

> > I thought I'd had qmail-send off every time I manipulated the file, but
> > I'm wondering if somehow I didn't <frown>.  Is there any way I can get
> > these out of the log?  I've restarted qmail many times, and it doesn't
> > seem to help <frown>.
> 
> You need to use a queue fixing program that understands your
> installation -- are you using big-todo?  Did you change conf-split?
> Both of these will affect how a queue fixing program works.

Does anyone know what the default Plesk install does?  If not, is there
anyway I can tell by looking at the installation?

> > So even though pornbyemail.com is a good candidate for a phony return
> > address that won't ever accept the email, I'm still not sure, because I
> > find delivery 5699 multiple times in the log, each with a different
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason Parsons | 1 Jun 2003 05:00

Re: Help please - new attack on an old problem


> I didn't do anything <frown>; it's a Plesk 5.0.5 installation.

One would assume that the Plesk RPMs install their queue correctly -- 
backing up the queue, removing the rpm, removing the queue if it is 
there, reinstalling the rpm, moving the queue as appropriate *before* 
starting qmail for the first time, then starting qmail *should* fix the 
queue.

>> You need to use a queue fixing program that understands your
>> installation -- are you using big-todo?  Did you change conf-split?
>> Both of these will affect how a queue fixing program works.
>
> Does anyone know what the default Plesk install does?  If not, is there
> anyway I can tell by looking at the installation?

You can tell if big-todo is installed by looking in queue/todo/.  If 
it's just a directory with files in it, you don't have big-todo.  If it 
has subdirectories in it, you have big-todo.  conf-split you can see by 
looking at how many subdirectories there are.  Or, in theory, you could 
ask Plesk support.

> But that still doesn't answer my question.  There's a different message
> number each time that "delivery 5699" is shown, so is there any way I
> can tell what message to look at when I see a failure for "delivery
> 5699"?

The logs for a delivery look as such:

starting delivery 6040: msg 434607 (6040 is the sequence number for
(Continue reading)

Permalink | Reply | 0 comments |
headers
C. Bensend | 1 Jun 2003 05:22

Re: building qmail-1.03

On Sat, May 31, 2003 at 06:55:12PM -0700, Chris Wilkes wrote:
> On Sat, May 31, 2003 at 10:50:15PM +0200, Henning Brauer wrote:
> > 
> > > Otherwise, search the archives and with Google for your error message.
> > > If you don't find a solution, post back here.  Many list members run
> > > qmail on OpenBSD, so it does work, but it may need a patch.
> > 
> > no, stock qmail works fine.
> 
> As long as we're guessing what the error was, could the error be perhaps
> occur when running qmail with a nosuid mounted /var?  Granted that
> doesn't show up at compile time.

That's what my bet is on - I built qmail on a 3.3-STABLE machine just
last week, and it is working like a dream.  Note, I set up separate
/var/qmail and /var/qmail/queue partitions, with the /var/qmail mounted
local, nodev, softdep.  If you aren't careful, you'll end up with the
nosuid flag on /var (qmail-queue needs to be SUID qmailq).

Benny

--

-- 

God is dead and I don't feel all too well either.... -- Ralph Moonen
Permalink | Reply | 1 comment |
headers
Bryan Fields | 1 Jun 2003 08:27

Re: Help please - new attack on an old problem

On Saturday 31 May 2003 21:41, Jeff Lasman wrote:

> > You need to use a queue fixing program that understands your
> > installation -- are you using big-todo?  Did you change conf-split?
> > Both of these will affect how a queue fixing program works.
>
> Does anyone know what the default Plesk install does?  If not, is there
> anyway I can tell by looking at the installation?

Look at the original queue and see if the todo directory is split like the 
queue directory is.

> > > So even though pornbyemail.com is a good candidate for a phony return
> > > address that won't ever accept the email, I'm still not sure, because I
> > > find delivery 5699 multiple times in the log, each with a different
> > > message number.
> >
> > It it fails with a temporary error, the message will be retried for the
> > queue lifetime.
>
> But that still doesn't answer my question.  There's a different message
> number each time that "delivery 5699" is shown, so is there any way I
> can tell what message to look at when I see a failure for "delivery
> 5699"?

Post your logs so we can see where this is happening

> > Yes, let them bounce after the queue lifetime expires.  This happens
> > automatically.  If you need to remove messages manually, you *must*
> > stop qmail-send, and then you can use one of the programs from
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux-Guru | 1 Jun 2003 10:53
Picon

Re: Spam Problem

Hi folks,

my spam problem seems to be solved - thanks to everybody who helped me
or gave me a hint where to have a look on.

Seems like it was the entry of the public IP-Address in the
tcp.smtp-file.
I also added the badmailfrom-file from kendryl.net. What do you think
about such a big "everyday-updated" badmailfrom-file?
Usually I am not a fan of blacklists or so but this _could_ be a
solution. I'd be glad to have some comments for it...

Greetings

Tobias
Permalink | Reply | 3 comments |
headers
Xavier Maysonnave | 1 Jun 2003 11:19

Re: Bad File Descriptor

Hi, All

Many thanks for your help.
I have successfully ran a fsck on my /var device.
Everything is clean now.
Have a nice week-end.

Regards.
Permalink | Reply | 0 comments |
headers
Doug S | 1 Jun 2003 11:20

Re: Help please - new attack on an old problem

Hi Jeff--

I may be able to help with one of these issues...

> From: "Jeff Lasman" <jblists <at> nobaloney.net>
  [--snip--]
> And finally, is there an easy way for me to find nonconsequential emails
> waiting in the queue, so I can empty it at regular intervals of
> non-returnable spam through a cron job?
  [--snip--]

At one point, I took issue with the thousands of undeliverable bounces
hanging around in the queues of my clustered qmail installation.  Now, we're
_supposed_ to let them retry for at least 4 to 5 days (per the RFC), but I
did some poking around in my queues and found:

** Legitimate bounces (ones going to real people) tend to get delivered
quickly.  By quickly, I mean the first attempt.  A few more on the 2nd or
3rd or 4th attempt while an admin restarts a server or whatever else has
happened to defer the bounce, but the vast majority of legitimate bounces
get delivered way sooner than 4 to 5 days.

** My queues were 96% full of undeliverable bounces.  4% of the messages in
my queues were not bounces.  We're talking a couple thousand (undeliverable)
bounces per queue as opposed less than a hundred non-bounce emails waiting
in each queue.

I saw many advantages to getting rid of the undeliverable bounces sooner
than queuelifetime and primarily two disadvantages.  The main disadvantage
is that there is a chance that a legitimate bounce gets double-bounced (to
(Continue reading)

Permalink | Reply | 4 comments |

Gmane