qmail Digest 4 Feb 1999 11:00:12 -0000 Issue 541

Topics (messages 21418 through 21481):

Fetchmail & QMail
        21418 by: "Thorsten Wasmann" <[EMAIL PROTECTED]>

Filters with qmail
        21419 by: "Sam" <[EMAIL PROTECTED]>
        21421 by: "Martin Staael" <[EMAIL PROTECTED]>
        21422 by: Andy Smith <[EMAIL PROTECTED]>
        21423 by: Stefan Paletta <[EMAIL PROTECTED]>
        21424 by: "Martin Staael" <[EMAIL PROTECTED]>
        21425 by: Sam <[EMAIL PROTECTED]>
        21426 by: Sam <[EMAIL PROTECTED]>
        21427 by: Pedro Melo <[EMAIL PROTECTED]>
        21428 by: "Martin Staael" <[EMAIL PROTECTED]>
        21429 by: Vince Vielhaber <[EMAIL PROTECTED]>
        21431 by: [EMAIL PROTECTED]
        21441 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
        21446 by: Mike Meyer <[EMAIL PROTECTED]>
        21454 by: Kai MacTane <[EMAIL PROTECTED]>
        21464 by: Matt Garrett <[EMAIL PROTECTED]>
        21470 by: "Sam" <[EMAIL PROTECTED]>
        21473 by: "Joe Garcia" <[EMAIL PROTECTED]>
        21476 by: "Aijaz A. Ansari" <[EMAIL PROTECTED]>
        21477 by: [EMAIL PROTECTED] (Lorens Kockum)

Million users
        21420 by: "Sam" <[EMAIL PROTECTED]>
        21435 by: Jere Cassidy <[EMAIL PROTECTED]>
        21440 by: Chris Johnson <[EMAIL PROTECTED]>
        21442 by: [EMAIL PROTECTED] (Lorens Kockum)
        21451 by: John Conover <[EMAIL PROTECTED]>

Unable to run qmail-remote from resource exthaustion PERMENENT error?
        21430 by: "Fred Lindberg" <[EMAIL PROTECTED]>
        21443 by: Pavel Kankovsky <[EMAIL PROTECTED]>
        21449 by: Sam <[EMAIL PROTECTED]>
        21479 by: "D. J. Bernstein" <[EMAIL PROTECTED]>

Three solutions for spam
        21432 by: Paul Graham <[EMAIL PROTECTED]>

I'm receiving non-exixstant users' mail...
        21433 by: Pietro Femmino' <[EMAIL PROTECTED]>
        21437 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>

Queue only + send manually (schedule)
        21434 by: Andrzej Szydlo <[EMAIL PROTECTED]>
        21438 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>

new-inject vs qmail-inject
        21436 by: Matthias Pigulla <[EMAIL PROTECTED]>
        21439 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
        21444 by: Mate Wierdl <[EMAIL PROTECTED]>

qmail: failure notice?
        21445 by: Franky Van Liedekerke <[EMAIL PROTECTED]>

Message rewriting with new-inject and ofmipd
        21447 by: "Pete Kazmier" <[EMAIL PROTECTED]>
        21453 by: Mate Wierdl <[EMAIL PROTECTED]>
        21455 by: Stefan Paletta <[EMAIL PROTECTED]>
        21478 by: "D. J. Bernstein" <[EMAIL PROTECTED]>

Web Mail server with Qmail
        21448 by: Sam <[EMAIL PROTECTED]>

Supervise/Tcpserver/cyclog
        21450 by: John Gonzalez/netMDC admin <[EMAIL PROTECTED]>
        21452 by: Sam <[EMAIL PROTECTED]>

Virtual Domain Configuration Help
        21456 by: MountaiNet Tech Support <[EMAIL PROTECTED]>

qmail_has_prog_delivery_but_has_x_bit_set._
        21457 by: Peter Gradwell <[EMAIL PROTECTED]>
        21459 by: Chris Johnson <[EMAIL PROTECTED]>
        21460 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
        21465 by: Mark Delany <[EMAIL PROTECTED]>
        21469 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
        21475 by: Mark Delany <[EMAIL PROTECTED]>

451 qq Trouble creating files in Queue
        21458 by: Peter Gradwell <[EMAIL PROTECTED]>
        21461 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>

Thanks guys
        21462 by: Peter Gradwell <[EMAIL PROTECTED]>

QMTP + VERP
        21463 by: Bruno Wolff III <[EMAIL PROTECTED]>
        21466 by: Stefan Paletta <[EMAIL PROTECTED]>
        21471 by: Bruno Wolff III <[EMAIL PROTECTED]>
        21474 by: Stefan Paletta <[EMAIL PROTECTED]>

checkpoppasswd permissions problems
        21467 by: Matt Garrett <[EMAIL PROTECTED]>
        21472 by: Chris Johnson <[EMAIL PROTECTED]>

mailx verbose?
        21468 by: Victor Tavares <[EMAIL PROTECTED]>
        21480 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>

mail for nonexistent user: wrong bounce?
        21481 by: Franky Van Liedekerke <[EMAIL PROTECTED]>

Administrivia:

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To bug my human owner, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [EMAIL PROTECTED]


----------------------------------------------------------------------


Hi together!
 
I´ve got a little Problem with fetchmail/qmail.
How do i tell fetchmail (running as daemon and is fetching mail every x hours via dialup-connection) to put mails like [EMAIL PROTECTED] on my Intranet-Mailserver (server.home.mydomain.com) running qmail-pop3d ? Due to ulimited POP3 useraccounts on mydomain.com i have to put the mail to the according Mailbox (like [EMAIL PROTECTED] ) on my homeserver.
Now my question:
Can i use /var/qmail/bin/sendmail as MDA in .fetchmailrc? If so, which parameters are needed?
Or should i use qmail-inject as MDA, if so which parameters i need?
 
TX in advance
 
Thorsten
 




Martin Staael writes:

> 
> Hi,
> 
> I need to setup a filter program with qmail. I have been looking for a while,
> but haven't found any programs that does the following :
> 
> Spam-filter.
> The qmail SMTP server is running as a open-realy, so we need to have some sort
> of spam filter - like checking if the mail looks like spam, and controlling
> that the user would only send xx mails within xx minutes.

Read the FAQ, and turn off your open relay.

> "Macro" filter :
> I need to be able to setup some conditions like:
> if the subject like 'something' and email '[EMAIL PROTECTED]' then
> delete/copy/forward/return to sender.

man dot-qmail
man qmail-command




Sam,

At 13:17 03-02-99 +0000, you wrote:

>Read the FAQ, and turn off your open relay.

I know how to turn off my open-realy. But I need a open-realy - or our
customers is not able to send mail through us.

>> "Macro" filter :
>> I need to be able to setup some conditions like:
>> if the subject like 'something' and email '[EMAIL PROTECTED]' then
>> delete/copy/forward/return to sender.

>man dot-qmail
>man qmail-command

I have to disappoint you, but this was not what I were looking for - sorry.
Please read again my letter, to understand what I mean.

Martin,




On Wed, 3 Feb 1999, Martin Staael wrote:

> Sam,
> 
> At 13:17 03-02-99 +0000, you wrote:
> 
> >Read the FAQ, and turn off your open relay.
> 
> I know how to turn off my open-realy. But I need a open-realy - or our
> customers is not able to send mail through us.

Read the FAQ again.  Ideally your customers should be using their ISP's
own mail server.

-- 
Andy J. Smith ... <[EMAIL PROTECTED]> ... <http://www.strugglers.net/andy>
Mail to [EMAIL PROTECTED] for PGP Key, or check the key servers ......
KeyID: 0xBF15490B FP: 0E42 36CB 5295 1E14 5360  6622 2099 B64C BF15 490B






Martin Staael wrote/schrieb/scribsit:
> Sam,
> 
> At 13:17 03-02-99 +0000, you wrote:

> I know how to turn off my open-realy. But I need a open-realy - or our
> customers is not able to send mail through us.

I think we'd be glad to hear why someone needs an open mail relay and to
propose another solution for you or improve qmail.
 
>>> "Macro" filter :
>>man dot-qmail
>>man qmail-command
> 
> I have to disappoint you, but this was not what I were looking for -
> sorry.
> Please read again my letter, to understand what I mean.

I wonder why Sam in particular did not point you at his maildrop.
Look for maildrop at Sam's page anyway: http://i.am/mrsam.
You can also use procmail.

Stefan





Andy,

At 13:42 03-02-99 +0000, you wrote:

>> I know how to turn off my open-realy. But I need a open-realy - or our
>> customers is not able to send mail through us.

>Read the FAQ again.  Ideally your customers should be using their ISP's
>own mail server.

Our customers will always use another ISP for dial-in, or have a direct connection. But we will still have to provide them with a SMTP server, that is the reason for the needed open-relay.

So we can't tell our customers to use another mail-server (SMTP) - and this would often be confusing for many customers.



Martin Staael
NetGroup A/S

St. Kongensgade 40H. 2.th.,1264 K�benhavn K., Tel.. +45 33691228, Fax. +45 33130066
---
 - Origin:     Glace Bleu d'origine... :)    ([EMAIL PROTECTED])




On Wed, 3 Feb 1999, Stefan Paletta wrote:

> 
> >>man dot-qmail
> >>man qmail-command
> > 
> > I have to disappoint you, but this was not what I were looking for -
> > sorry.
> > Please read again my letter, to understand what I mean.
> 
> I wonder why Sam in particular did not point you at his maildrop.

Because in very simple cases, the rudimentary processing available from
qmail-command is good enough, and does not require additional software.
And, for complicated cases, you need more than just a standalone maildrop.





On Wed, 3 Feb 1999, Martin Staael wrote:

> 
> Andy,
> 
> At 13:42 03-02-99 +0000, you wrote:
> 
> >> I know how to turn off my open-realy. But I need a open-realy - or our
> >> customers is not able to send mail through us.
> 
> >Read the FAQ again.  Ideally your customers should be using their ISP's
> >own mail server.
> 
> Our customers will always use another ISP for dial-in, or have a direct
> connection. But we will still have to provide them with a SMTP server, that is
> the reason for the needed open-relay.

If you were to search the mailing list archives, you would discover that
on average we have one person a month repeating the same exact claim,
almost word for word.

No, you don't need an open relay, no matter how convinced you are
otherwise.  The age of open relays has long come, and gone, and it's just
a matter of time before you'll get listed on any one of several public
blacklists of open relays, and then you customers won't be able to send
E-mail through your server to many destinations anyway.  A lot good will
then your open relay be good for you.  Sure, it will be open, but quite a
few places will simply not accept mail from it.

I do not believe that there are any solutions out there that will satisfy
your requirements, because your requirements are rather unique, and I
can't recall anyone around here who also has a similar need for an open
relay, despite the fact that they also have plenty of customers who use
other ISPs for dialup.

Their customers are either provided instructions on how to use their ISP's
mail server, or they set up an authentication scheme by which their
customers can unblock their current IP address for a limited time.  Some
combination of the above always seem to satisfy that lone once-a-month
individual who claims a need to have an open relay.






On 03-Feb-99 Martin Staael wrote:
> 
> Andy,
> 
> At 13:42 03-02-99 +0000, you wrote:
> 
>>> I know how to turn off my open-realy. But I need a open-realy - or our
>>> customers is not able to send mail through us.
> 
>>Read the FAQ again.  Ideally your customers should be using their ISP's
>>own mail server.
> 
> Our customers will always use another ISP for dial-in, or have a direct
> connection. But we will still have to provide them with a SMTP server, that
> is
> the reason for the needed open-relay.

Check solutions in www.qmail.org for SMTP after POP solutions that will allow
you to put login/password style security in your SMTP server.

Much better... And you will be able to send me mail also.. :)


---
Pedro Melo                      [EMAIL PROTECTED]
IP - Engenharia                 http://ip.pt/
Tel: +351-1-3166740             Av. Duque de Avila, 23
Fax: +351-1-3166701             1049-071 LISBOA - PORTUGAL
Linux: up 13 days and 13:05, 4 users,  load average: 0.09, 0.50, 0.57





Petr,

At 15:11 03-02-99 +0000, you wrote:

>1. If your customers have static IP, setup a database for tcpserver 
>which exports RELAYCLIENT="" for those special IPs (see FAQ 5.4)

They don't. The use dial-in from around the world.

What I need is a program to check that a user is not sending more than xx
mails within yy minutes. (ie. 30 mails within 5min).

It would be nice if a program could do a match on the mails - so that if
someone has send 5 mails in a row that a program did match the previous
mail - and if at least 70% percent of the previous mail were matched then
this mail would probally be spam. With spam mails normally the
receiver/sender and some of the content is changed. So it is actually very
easy to do a match whether a mail is spam - if just enough of these has
been sent.

Can you follow this?

>2. If your customers ahve dynamic IPs (or connect from all around 
>theh world), go to www.qmail.org and find there Open-SMTP patches (in 
>fact it means that after successful POP3 authentication, you open a 
>relay for that IP for some time - like 5 or 10 minutes).

I have considered this solution. But most POP3 clients such as Netscape and
Eudora actually DO send mail by SMTP first, rather than checking mail first.

I'm really without a clue here. I hope someone has developed as spam filter
that do a match on mails - for preventing spam or check whether the host is
sending more than xx mails within yy min.

Martin,




On Wed, 3 Feb 1999, Martin Staael wrote:

> 
> Andy,
> 
> At 13:42 03-02-99 +0000, you wrote:
> 
> >> I know how to turn off my open-realy. But I need a open-realy - or our
> >> customers is not able to send mail through us.
> 
> >Read the FAQ again.  Ideally your customers should be using their ISP's
> >own mail server.
> 
> Our customers will always use another ISP for dial-in, or have a direct
> connection. But we will still have to provide them with a SMTP server, that is
> the reason for the needed open-relay.
> 
> So we can't tell our customers to use another mail-server (SMTP) - and this
> would often be confusing for many customers. 

Look on www.qmail.org for a package that allows relaying after checking
pop mail.  I can't think of the name right now.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: [EMAIL PROTECTED]   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================







Martin Staael <[EMAIL PROTECTED]> writes on 3 February 1999 at 15:00:35 +0100

 > Our customers will always use another ISP for dial-in, or have a direct
 > connection. But we will still have to provide them with a SMTP server, that is
 > the reason for the needed open-relay.
 > 
 > So we can't tell our customers to use another mail-server (SMTP) - and this
 > would often be confusing for many customers. 

You can try to fight this one if you want, but it's going to be
trouble.  If you leave the relay open, spammers will find and use it.
Eventually, you'll end up on the RBL and the ORBS blocking lists, and
your customers will find they can't communicate very many places.  You
can't win this fight, I'd recommend you take the clever step of not
getting into it.

If your users are too ignorant/lazy/unreliable to reconfigure to use
the servers approrpiate to where they're dialed in through, you might
look at some of the smtp-after-pop solutions (patches) available on
www.qmail.org, whereby an authenticated POP session is used to open
relaying to that same IP address for a time period.  This gives you
much of what you want without leaving you a fully open relay.
-- 
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!




If you're going to run an open relay, don't run it on port 25.  Run it on
1025 or some other high port, and only let your customers know what the port
is.

Yes, this is security through obscurity, but it should keep spammers from
finding your relay.

And, like everyone else is saying, RTFM.

--Adam

-----Original Message-----
From: Martin Staael <[EMAIL PROTECTED]>
To: Petr Novotny <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, February 03, 1999 9:26 AM
Subject: Re: Filters with qmail


:Petr,
:
:At 15:11 03-02-99 +0000, you wrote:
:
:>1. If your customers have static IP, setup a database for tcpserver
:>which exports RELAYCLIENT="" for those special IPs (see FAQ 5.4)
:
:They don't. The use dial-in from around the world.
:
:What I need is a program to check that a user is not sending more than xx
:mails within yy minutes. (ie. 30 mails within 5min).
:
:It would be nice if a program could do a match on the mails - so that if
:someone has send 5 mails in a row that a program did match the previous
:mail - and if at least 70% percent of the previous mail were matched then
:this mail would probally be spam. With spam mails normally the
:receiver/sender and some of the content is changed. So it is actually very
:easy to do a match whether a mail is spam - if just enough of these has
:been sent.
:
:Can you follow this?
:
:>2. If your customers ahve dynamic IPs (or connect from all around
:>theh world), go to www.qmail.org and find there Open-SMTP patches (in
:>fact it means that after successful POP3 authentication, you open a
:>relay for that IP for some time - like 5 or 10 minutes).
:
:I have considered this solution. But most POP3 clients such as Netscape and
:Eudora actually DO send mail by SMTP first, rather than checking mail
first.
:
:I'm really without a clue here. I hope someone has developed as spam filter
:that do a match on mails - for preventing spam or check whether the host is
:sending more than xx mails within yy min.
:
:Martin,
:








On Wed, 3 Feb 1999, Sam wrote:
> No, you don't need an open relay, no matter how convinced you are
> otherwise.  The age of open relays has long come, and gone, and it's just
> a matter of time before you'll get listed on any one of several public
> blacklists of open relays, and then you customers won't be able to send
> E-mail through your server to many destinations anyway.  A lot good will

Oh, tosh. I've got a server listed on those lists - has been for close
to a year. It runs mail lists, and in that year, I've had exactly two
people show up from places that honored those blocks.

I deleted them from the list, and told them to resubscribe from a less
anal ISP.

        <mike






Text written by Martin Staael at 02:30 PM 2/3/99 +0100:
>Sam,
>
>At 13:17 03-02-99 +0000, you wrote:
>
>>Read the FAQ, and turn off your open relay.
>
>I know how to turn off my open-realy. But I need a open-realy - or our
>customers is not able to send mail through us.

No, you do not. What you need is a *selective* relay, which will allow only
_your customers_ to send mail through you.

An *open* relay, which will allow _anyone_ to send mail through you, will
eventually be discovered and used by spammers and land you on a blackhole
list.

Really, read the FAQ. It tells you how to set up a selective relay.

-----------------------------------------------------------------
                             Kai MacTane
                         System Administrator
                      Online Partners.com, Inc.
-----------------------------------------------------------------
>From the Jargon File: (v4.0.0, 2/1/1999)

steam-powered /adj./ 

Old-fashioned or underpowered; archaic. This term does not have a
strong negative loading and may even be used semi-affectionately for
something that clanks and wheezes a lot but hangs in there doing
the job. 





Look. I very much doubt that Martin Staael <[EMAIL PROTECTED]> REALLY
wants to run an open relay. What most ISPs want to allow are

Internet ---> SMTP ---> local users

Internet <--- SMTP <--- local users

local users <--- SMTP <--- local user

and disallow

Internet ---> SMPT ---> Internet

You generally must have a pretty firm idea as to who your local users
are and what their IP numbers will be, whether they're local dialup lines or
remote network machines. Simply use tcpserver with a /etc/tcprules.d/ file
like so:
127.0.0.1:allow,RELAYCLIENT=""
<local IP>:allow,RELAYCLIENT=""
# standard operating procedure

<local users' IP>:allow,RELAYCLIENT=""
<range of local users' IPs>:allow:RELAYCLIENT=""
# I appear as an open relay to my local users...

:allow
# but not to the rest of the Internet
Ta da! Done. The only reason I can think of that Martin can't use this scheme
is if he has so many users that the rules file would be unmanagably large, or
that his users are allowed to change their IP numbers at random. In that case,
the pop-before-smtp patches already spoken of would be the only way to go.
Open relay is a bad idea in any language. Much more preferable to teach all of
your users to "check your mail before sending new mail" than to have your
carefully configured open relay cut off from all of the sites your users want
to e-mail.
--
Matt Garrett, Network Engineer
Superior Open Systems
[EMAIL PROTECTED]




Matt Garrett writes:

> Look. I very much doubt that Martin Staael <[EMAIL PROTECTED]> REALLY
> wants to run an open relay. What most ISPs want to allow are

Actually, he thinks he does.  As I mentioned earlier, usually there's an
inquiry of this kind about once a month on this list.

These organizations provide either web hosting, or other non-dialup
services, and they do not maintain any dialup facilities on their own. 
Their clients have their own dialup accounts with separate ISPs.  For some
reason he believes that his clients cannot use the mail relays from their
own ISPs, and are required to use his.  Either that, or he does sell dialup
access, but believes that his clients should be allowed to access his mail
servers from other ISPs.

What these people are not realizing is that this business model is simply
no longer compatible with the way that the Internet is right now.  This
kind of a setup - open relaying for everyone - might've been acceptable and
the norm some time ago, but these days, it no longer is.  They can't expect
to enforce their own business model onto the rest of the Internet, they
must somehow fit their business model within the established guidelines and
requirements, that's it.  There are many technical solutions available that
will allow his customers to authenticate themselves, and he should simply
choose the best one for his situation.




i sent him an email because we are going to be doing EXACTLY what he will be
doing.

1: All of our clients are using Outlook or Outlook Express, this is a
requirement, since it checks pop before it does any smtp transactions.

2: All our clients are using SSL

3: I will be releasing a first run tarpit patch sometime late today, early
tommorow, that will make them pay should they figure out 1 and 2, and give
you time to hunt them down.

VERY simple and it will close you down pretty damn well considering that
most spammers have the brainpower of a twig.

Joe

> -----Original Message-----
> From: Sam [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 03, 1999 4:44 PM
> Cc: [EMAIL PROTECTED]
> Subject: Re: Filters with qmail
>
>
> Matt Garrett writes:
>
> > Look. I very much doubt that Martin Staael <[EMAIL PROTECTED]> REALLY
> > wants to run an open relay. What most ISPs want to allow are
>
> Actually, he thinks he does.  As I mentioned earlier, usually there's an
> inquiry of this kind about once a month on this list.
>
> These organizations provide either web hosting, or other non-dialup
> services, and they do not maintain any dialup facilities on their own.
> Their clients have their own dialup accounts with separate ISPs.  For some
> reason he believes that his clients cannot use the mail relays from their
> own ISPs, and are required to use his.  Either that, or he does
> sell dialup
> access, but believes that his clients should be allowed to access his mail
> servers from other ISPs.
>
> What these people are not realizing is that this business model is simply
> no longer compatible with the way that the Internet is right now.  This
> kind of a setup - open relaying for everyone - might've been
> acceptable and
> the norm some time ago, but these days, it no longer is.  They
> can't expect
> to enforce their own business model onto the rest of the Internet, they
> must somehow fit their business model within the established
> guidelines and
> requirements, that's it.  There are many technical solutions
> available that
> will allow his customers to authenticate themselves, and he should simply
> choose the best one for his situation.
>





On Wed, Feb 03, 1999 at 09:31:21AM -0500, Vince Vielhaber wrote:
...
> Look on www.qmail.org for a package that allows relaying after checking
> pop mail.  I can't think of the name right now.
...
 
FYI: one of the options is smtp-poplock.  I use that.  However, there
were several things in the INSTALL file that didn't work for me, and
_much_ tweaking was required for my setup.  If you're interested,
look at my post on this list (available at
http://www.ornl.gov/its/archives/mailing-lists/qmail/1999/01/msg01254.html
).

 

---  -   ENoor Creations, Inc.   http://www.enoor.com/   (847)253-5071
------   
-  ---   Internet Presence and Business Software Provider




On the qmail list [EMAIL PROTECTED] wrote:
>
>Oh, tosh. I've got a server listed on those lists - has been for close
>to a year. It runs mail lists, [...]

And I suppose that you don't care that your server is probably
being used to send spam all over the world ?

-- 
#include <std_disclaim.h>                          Lorens Kockum




Matthew Kirkwood writes:

> That's basically my point.  Whether Solaris, Linux or BSD is "better"
> (whatever that means in this case) is not too relevant to me.  They would
> all, I think, do a more than adequate job.
> 
> And NT/Exchange simply can't cope with much more than a light load.

Linux+Samba is faster than NT server under the exact same hardware.

http://www.zdnet.com/sr/stories/issue/0,4537,2196106,00.html





Sorry to get a little off topic for this particular thread, but...

Jaye Mathisen wrote:

> I did not save all my testdata unfortunately, but at one time, I had 2
> FreeBSD P6 boxes, NFS mounting a Netapp F540, using Maildir for delivery,
> and several boxes generating the email in front.  The P6's were
> loadbalanced with a Cisco LocalDirector.

We are doing something very similar with an Alteon ACEDirector balancing to 4
Alpha's running Redhat and qmail.  Backend network is a Netapp F230 that is
handling the Maildirs.  I was wondering a few things.

a)  Almost all delivery (from sending client to remote client) takes 3 to 4
minutes.  However, If I look in the receiving client's Maildir/new after the
sending client sends the message, it is there in 5 to 10 seconds.   Any POP3
connection simply does not notice the file is there even though it is present on
all 4 servers (via the Netapp, of course).  Most likely this is the result of
some caching that the front end servers are doing, but we haven't been able to
track it down exactly.  I was curious if you, or anyone else running a similar
setup, saw anything like this issue.

b) You said "At one time"  you were running this setup.  Have you changed to
something better?  After upgrading our News server from using a NetApp F210 to a
DPT UW2-SCSI Raid our KB/second rate (accepting 3 news feeds) increased by up to
200% (240KB to 720KB) and I would think that similar performance increases may
be found for mail, but I am still in love with the fact that aside from the
Netapp which has been very reliable, we have no single point of failure in the
system.   The load balancing switch would be one too I guess, but it has been
reliable and a life-saver in many cases.

c) You say you had several servers generating email... Right now all servers do
POP3 and SMTP balancing and all are connnected to the backend... if we would
upgrade to some Raid solution, only one would have access, and I cringe at
implementing NFS on Linux so I though the following solution might work....

Imagine 3 servers:
FRONT (could be a group)
REMOTE (also could be group)
LOCAL (single server with raid)

SMTP would go to FRONT, which then through control/smtproutes would decide
whether to pass the message on to LOCAL or REMOTE.  POP3 connections would go
directly to LOCAL.  Based on this list's collective experience, would you say
that this is a scalable solution?  Better than the current one explained?
After sever tuning qmail-filter (used with Sam's maildrop) we have lowered the
load considerably and won't have to make any changes for a bit, but are looking
to the future.

d) Anyway.. another thing... I am sure most of you are aware of the fact that
qmail uses a lot of file descriptors.   Even after setting
/proc/sys/kernel/file-max to 4096, our main server hit this limit shortly after
enabling logging (using splogger).   We haven't been able to do logging in some
time because of the intense increase in load that it creates (we are logging to
the local disk of each machine)  and the fact that we eventually run out of FDs
(we uppped it to 8192 recently and haven't hit that... but logging is off).  Is
qmail-2.0 going to use the same structure of piping one process to another, or
will it be threaded and more efficient when the use of file descriptors is
concerned?   Is there some URL for qmail-2.0 yet that may shed some light on the
changes and the timetable for its release?


> I have no doubts a million messages a day would be not impossible at all.

Even with as little as 20-30K users, I am certain that 1million messages /per
day (incoming and outgoing) would not be that unthinkable.

Thanks in advance for any thoughts that any one has on any of the questions.


--
------------------------------------------------------------------------
// Jere Cassidy  -  System Administration - D&E SuperNet
        email: [EMAIL PROTECTED]    phone: (717)738-7054
        web: http://www.desupernet.net/jere
        pager/pcs: [EMAIL PROTECTED] - (717)203-0042
~~~ "While sowing the seeds of Utopia,
 you invoked a convenient amnesia" -BR ~~~
------------------------------------------------------------------------






On Wed, Feb 03, 1999 at 11:39:07AM -0500, Jere Cassidy wrote:
> Sorry to get a little off topic for this particular thread, but...
> 
> Jaye Mathisen wrote:
> 
> > I did not save all my testdata unfortunately, but at one time, I had 2
> > FreeBSD P6 boxes, NFS mounting a Netapp F540, using Maildir for delivery,
> > and several boxes generating the email in front.  The P6's were
> > loadbalanced with a Cisco LocalDirector.
> 
> We are doing something very similar with an Alteon ACEDirector balancing to 4
> Alpha's running Redhat and qmail.  Backend network is a Netapp F230 that is
> handling the Maildirs.  I was wondering a few things.
> 
> a)  Almost all delivery (from sending client to remote client) takes 3 to 4
> minutes.  However, If I look in the receiving client's Maildir/new after the
> sending client sends the message, it is there in 5 to 10 seconds.   Any POP3
> connection simply does not notice the file is there even though it is present on
> all 4 servers (via the Netapp, of course).  Most likely this is the result of
> some caching that the front end servers are doing, but we haven't been able to
> track it down exactly.  I was curious if you, or anyone else running a similar
> setup, saw anything like this issue.

This came up a few days ago, and the problem was that the clocks on the NFS
server and the machine running qmail-pop3d were out of synch. For some reason,
qmail-pop3d won't retrieve a message for you if the modified time is in the
future. (To prove this to yourself, touch -t a file in your Maildir/new to some
time in the future.)

Chris




On the qmail list [EMAIL PROTECTED] wrote:
>
>a)  Almost all delivery (from sending client to remote client) takes 3 to 4
>minutes.  However, If I look in the receiving client's Maildir/new after the
>sending client sends the message, it is there in 5 to 10 seconds.   Any POP3
>connection simply does not notice the file is there even though it is present on
>all 4 servers (via the Netapp, of course).

There was someone a few days agos (yesterday?) who had this
problem; the reason was that the POP3 Maildir reader ignored
mails dated in the future, the solution was obviously to sync
the times on the machines.

Syncing times on networked machines is also very
useful/important in investigating all manner of network
problems; NTP is your friend.

>Is there some URL for qmail-2.0 yet that may shed some light on the
>changes and the timetable for its release?

Changes, dunno, timetable, certainly not, it'll be out when it's
ready (forgot who said that, Russ or mrsam IIRC).

-- 
#include <std_disclaim.h>                          Lorens Kockum




Jere Cassidy writes:
> 
> We are doing something very similar with an Alteon ACEDirector balancing to 4
> Alpha's running Redhat and qmail.  Backend network is a Netapp F230 that is
> handling the Maildirs.  I was wondering a few things.
>

Just out of curiosity, has anyone thought about, (or tried,) using a
cluster like Beowulf for Linux as a mail system? It has load
balancing, and fail over.

        Thanks,

        John

-- 

John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA.
VOX 408.370.2688, FAX 408.379.9602
[EMAIL PROTECTED], http://www2.inow.com/~conover/john.html





On 3 Feb 1999 07:56:25 -0000, D. J. Bernstein wrote:

>This is a bug in your operating system.

Yes. This is where a small change in qmail could cause it to be more
robust, even on a less-than-perfect OS.

>On bug-free systems, the only way for qmail-rspawn to generate that
>message is for execve() to return an error that fails error_temp():
>normally ENOTDIR, ENAMETOOLONG, ENOENT, ELOOP, EACCES, ENOEXEC, E2BIG,
>or EFAULT. None of these can be caused by temporary failures; they are
>permanent (and quite serious) configuration errors.

Permanent(OS) and Permanent(mail) are 2 different things. I don't see
why e.g. ENOENT should cause the message to be bounced. It's not a
permanent problem with the message, and over the queue-life of the
message it's not a permanent config problem either. If the sysadmins
doesn't fix it, it becomes a (mail) permanent error when the message
times out in the queue.

>What happened to you, presumably, is that crt0.o tried to load a shared
>library, failed because it was out of memory, and incorrectly decided to
>exit with some arbitrary code, never mind the fact that exit codes have
>meanings. It should instead have terminated the process with SIGKILL.

More or less. Again, the error is permanence from the point of view of
the application, but shouldn't cause the message to bounce immediately.

-Sincerely, Fred

(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)






On 3 Feb 1999, D. J. Bernstein wrote:

> On bug-free systems, the only way for qmail-rspawn to generate that
> message is for execve() to return an error that fails error_temp():
> normally ENOTDIR, ENAMETOOLONG, ENOENT, ELOOP, EACCES, ENOEXEC, E2BIG,
> or EFAULT. None of these can be caused by temporary failures; they are
> permanent (and quite serious) configuration errors.

According to Single Unix Spec v2, execve() may fail with ENOMEM and
ETXTBSY too. And they are interpreted as temporary failures by qmail. You
don't remember the details of your own code. :)

Anyway, I do not think it should be a PERMANENT error when qmail-rspawn
can't execute qmail-remote for WHATEVER reason. Indeed, it is a serious
configuration error if qmail-remote is corrupted, deleted, or having bad
permission but it seems to be a bit harsh not to give an administrator a
chance to fix the problem.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"





On Wed, 3 Feb 1999, Pavel Kankovsky wrote:

> Anyway, I do not think it should be a PERMANENT error when qmail-rspawn
> can't execute qmail-remote for WHATEVER reason. Indeed, it is a serious
> configuration error if qmail-remote is corrupted, deleted, or having bad
> permission but it seems to be a bit harsh not to give an administrator a
> chance to fix the problem.

A little note on a related subject.  I coded maildrop to return with a
temporary error pretty much for any kind of a failure.  So far that proved
to be the best design feature in the entire utility.  Little things like
operating system oddities, and user misconfiguration, all resulted in a
slight delay in mail that many recipients hardly noticed, instead of a
slew of annoying bounces that would've given everyone a black eye, and
forced me to wear a paper bag over my head, for a month.






Pavel Kankovsky writes:
> According to Single Unix Spec v2, execve() may fail with ENOMEM and
> ETXTBSY too. And they are interpreted as temporary failures by qmail. You
> don't remember the details of your own code. :)

Pay attention. Temporary errors during a message's lifetime produce
``deferral: Unable to run qmail-remote.'' The question here was about
``failure: Unable to run qmail-remote.''

The answer is that this failure can only be caused by permanent errors
from execve(), reflecting serious configuration problems, or by OS bugs.
In this case the problem was an OS bug.

I agree that there's not much harm in treating all of these as temporary
errors. However, no matter what qmail does, the OS bug has to be tracked
down and fixed.

---Dan





as far as i'm concerned this started because russ suggests rejecting mail
from sites that don't meet certain DNS tests (PTR and or MX records)
because sites that meet these criteria are often dial-up spam sources.
i suggest blocking traffic from places that have a history of sending
spam.  like you we don't have any global in-bound mail filtering and my
group has resisted suggestions that we install such filtering.

i will admit that part of my motivation is my direct experience with spam.
i get very little (and almost all of it is addressed to webmaster or uucp)
and except for one or two notable exceptions we don't have a systems
problem with spam (i.e. it doesn't have a significant effect on our ability
to deliver mail to our users).

    shag> I think we're arguing two different things here.  When I'm
    shag> talking about blocking dialup users, I'm talking about preventing
    shag> my users on my network from sending mail directly out.  I'm not
    shag> talking about using the DUL, or RBL, or anything else to prevent
    shag> inbound mail.

-- 
 paul
    [EMAIL PROTECTED]    |public keys at:
                            |     http://urth.acsu.Buffalo.EDU/~pjg/key.html
    if the above contains opinions they are mine unless marked otherwise.




Hi Qmailers.
I'm using Qmail on a Linux Debian system. What's the problem? If I send mail
to [EMAIL PROTECTED], where nonex is a non-existant user, I (the user krazy)
receive that mail. Root is aliased to krazy. Postmaster (and mailer-daemon)
put their mail on a file.

Where should I investigate to understand my problem?

Thanks, and bye.

--+ Pietro Femmino' <[EMAIL PROTECTED]> 'The Krazy One' +-- 
---->  "To Reign is Worth Ambition, Though in Hell.
     Better to Reign in Hell Than Serve in Heaven" <---

*** TaRT_Tagline: Any given program will expand to fill available memory.




- Pietro Femmino' <[EMAIL PROTECTED]>:

| I'm using Qmail on a Linux Debian system. What's the problem? If I send mail
| to [EMAIL PROTECTED], where nonex is a non-existant user, I (the user krazy)
| receive that mail. Root is aliased to krazy. Postmaster (and mailer-daemon)
| put their mail on a file.
| 
| Where should I investigate to understand my problem?

Look for ~alias/.qmail-default, which controls mail to non-existent
users.  If the file does not exist, such mail ought to bounce.
Exception: A wildcard entry in /var/qmail/users/cdb (plain text in
users/assign) can have the same effect.  Failing all these, look at
your virtualdomains file, if you have one.  When everything else
fails, look at Delivered-To: header fields in the incoming mail for
clues.

- Harald




Hi,

I'd like to queue messages and then send them all when the network link is up.
I know I can use uucp over TCP for that, but it may decrease security.
I'd prefer to avoid uucp.

Can I find any docs or examples somwhere?

Any suggestions welcome.

Thanks,

Andrzej




- Andrzej Szydlo <[EMAIL PROTECTED]>:

| I'd like to queue messages and then send them all when the network link is up.
| I know I can use uucp over TCP for that, but it may decrease security.
| I'd prefer to avoid uucp.
| 
| Can I find any docs or examples somwhere?

Use serialmail.  Available from Dan's FTP site.

- Harald




"D. J. Bernstein" wrote:
> The mess822 package is still experimental, but new-inject is eventually
> going to replace qmail-inject. It supports several new features and has
> a much cleaner internal design.

Where can I find more information about "new-inject"?

Matthias
-- 
   w e b f a c t o r y | matthias pigulla
      www.webfactory.de  [EMAIL PROTECTED]




- Matthias Pigulla <[EMAIL PROTECTED]>:

| "D. J. Bernstein" wrote:
| > The mess822 package is still experimental, but new-inject is [...]
| 
| Where can I find more information about "new-inject"?

Get the mess822 package from Dan's FTP server.

- Harald




   "D. J. Bernstein" wrote:
   > The mess822 package is still experimental, but new-inject is eventually
   > going to replace qmail-inject. It supports several new features and has
   > a much cleaner internal design.
   
   Where can I find more information about "new-inject"?
   
in the mess822 package there is man new-inject.

Mate




Hi,

I'm seeing some strange things in my qmail log file (see below):
somebody seems to be mailing
to "[EMAIL PROTECTED]",  but when I try to send to one
of the following:

Boghe Bruno
Boghe [EMAIL PROTECTED]
Boghe_Bruno
[EMAIL PROTECTED]

I always get an error with something like "no such user".

On the other hand, the client gets a failure notice message fro
MAILER-DAEMON  with the message:

>> Subject: failure notice
>>
>> Hi. This is the qmail-send program at hercules.telenet-ops.be.
>>
>> I'm afraid I wasn't able to deliver your message to the following
addresses.
>> This is a permanent error; I've given up. Sorry it didn't work out




But qmail doesn't give "following addresses", so people are wondering
why they get this mail.


Here is the part of the logfile:




918056657.542376 info msg 49273: bytes 7986 from
<[EMAIL PROTECTED]> qp 493 uid 1008
918056657.726019 starting delivery 91878: msg 49273 to local
[EMAIL PROTECTED]
ps.be
918056657.726115 status: local 1/40 remote 10/40
918056657.726774 starting delivery 91879: msg 49279 to remote
[EMAIL PROTECTED]
918056657.726947 status: local 1/40 remote 11/40
918056657.727742 end msg 49293
918056657.843907 starting delivery 91880: msg 49273 to local
[EMAIL PROTECTED]
ps.be
918056657.843935 status: local 2/40 remote 11/40
918056657.843951 starting delivery 91881: msg 49273 to local
[EMAIL PROTECTED]
ps.be
918056657.843976 status: local 3/40 remote 11/40
918056657.843992 starting delivery 91882: msg 49273 to remote
[EMAIL PROTECTED]
918056657.844016 status: local 3/40 remote 12/40
918056657.862791 delivery 91878: failure:
Receipient_email_address_contains_illegal_charact
ers./
918056657.971849 status: local 2/40 remote 12/40
918056657.972033 delivery 91880: failure:
Receipient_email_address_contains_illegal_charact
ers./
918056657.972207 status: local 1/40 remote 12/40
918056657.972383 delivery 91881: failure:
Receipient_email_address_contains_illegal_charact
ers./
918056658.005969 status: local 0/40 remote 12/40
918056658.006044 delivery 91879: success:
10.0.49.33_accepted_message./Remote_host_said:_25
0_OK/
918056658.033540 status: local 0/40 remote 11/40
918056658.034143 end msg 49279






After looking through the mess822 documentation, I'm left with the
following question:

Why not integrate rewriting of messages in one common location instead
of the entry points to the qmail system (ofmipd and new-inject)?
Perhaps in qmail-queue?

I understand that connections via smtp (not ofmip) should not be
subject to rewriting, but running both qmail-smtpd and ofmipd seems
overkill.  I'm also imagining the trouble an administrator who is
trying to force message rewriting would have.  For example, if users
simply pointed to the qmail-smtpd port rather than the ofmipd port
then message rewriting would be bypassed.

Does anyone see any benefits to setting an environment variable via
tcpserver such as NOREWRITE.  If NOREWRITE is set, then rewriting
should not occur.  A site administrator would only have to determine
which ip addresses are non-local.  

Even if the rewriting is not integrated into one common location, this
might be a better alternative than running ofmipd and qmail-smtpd.
Simply add the rewriting code to qmail-smtpd and check for NOREWRITE.

Comments?




   Simply add the rewriting code to qmail-smtpd and check for NOREWRITE.

Is not this aginst rfc821 to do any rewriting during an smtp
connection?  Like: 

mail from: [EMAIL PROTECTED]

but the envelope sender gets transformed to 

[EMAIL PROTECTED]

Mate





Pete Kazmier wrote/schrieb/scribsit:

> Why not integrate rewriting of messages in one common location instead
> of the entry points to the qmail system (ofmipd and new-inject)?
> Perhaps in qmail-queue?

Both new-inject and ofmipd (qmail-inject partially) manipulate the
RFC822 message header, while qmail-queue (and qmail-smtpd of course)
don't care to look at it. Doing RFC822 parsing/rewriting in qmail-queue
breaks modularity, i.e. you cannot let messages flow completely apart from
any rewriting or parsing. qmail tries to parse as little as possible, what
is an advantage in general.

> Does anyone see any benefits to setting an environment variable via
> tcpserver such as NOREWRITE.  If NOREWRITE is set, then rewriting
> should not occur.  A site administrator would only have to determine
> which ip addresses are non-local.

Your wish is granted:

#!/bin/sh
if [ -n "$OFMIPCLIENT" ] ; then
        exec /usr/local/sbin/ofmipd
else
        exec /var/qmail/bin/qmail-smtpd
fi


Stefan





It's easy to switch from an existing FAQ 5.5 setup to running ofmipd and
qmail-smtpd simultaneously. Set up qmail-smtpd on another IP address;
change your MX record; wait for incoming SMTP connections to stop using
the old IP address; and change the old qmail-smtpd to ofmipd, denying
connections from unauthorized hosts.

Pete Kazmier writes:
> For example, if users
> simply pointed to the qmail-smtpd port rather than the ofmipd port
> then message rewriting would be bypassed.

And they'd also be unable to relay to other hosts. This sort of mistake
is easy to catch.

---Dan




On Mon, 1 Feb 1999,

< sigh... Geocities' servers are now regurgitating mail that's been stuck
for two days in there >

Lucas do R. B. Brasilino da Silva wrote:

> I'd like to provide the same service to these students. Is there 
> some Web based Mail server that works with Qmail ??
> In time: At the same machine is running apache (thanks apache group! :) ).

I have beta quality software that does that, providing that you use
Maildirs, not mailbox files.  See http://sqwebmail.listbot.com for more
info.






I'm wondering if anyone here is running the above combination?

I have qmaild running under tcpserver at the time, but now our machine has
become busy enough that the pop3 service is looping (in inetd) and want to
replace it with tcpserver.

I've also noticed that the single process on the machine that is a hog is
the syslog process, so i also want to replace this with cyclog.

What my question is:

I'm running qmail1.03 with Bruce Guenters vmailmgrd package (a checkpw
replacement) -- what kind of command lines is everyone else running?

I need one for qmail and for qmail-pop3d -- anyone have some suggestions?
Linux/Slackware.

  _    __   _____      __   _________      
______________  /_______ ___  ____  /______  John Gonzalez/Net.Tech
__  __ \ __ \  __/_  __ `__ \/ __  /_  ___/ MDC Computers/netMDC!
_  / / / `__/ /_  / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052
/_/ /_/\___/\__/ /_/ /_/ /_/\__,_/  \___/ http://www.netmdc.com
[---------------------------------------------[system info]-----------]
 11:20am  up 115 days, 14:59,  4 users,  load average: 0.12, 0.15, 0.10







On Wed, 3 Feb 1999, John Gonzalez/netMDC admin wrote:

> I need one for qmail and for qmail-pop3d -- anyone have some suggestions?
> Linux/Slackware.

Oh, yes, I got one of those.  Its syslog is a denial-of-service attack
just waiting to happen.

Put a dash in front of every filename in /etc/syslog.conf, and restart
syslogd.  That turns off the syncing.  I've found that it also depends on
your hard disk.  Some hard disks don't notice the extra syncs, others bog
down completely.





Ok....I need a little bit of pointing in the right direction yet again.  
We are currently running our pop3 server on ns2.mounet.com
We've got the NS configuration setup like so:

                IN      MX      0       ns2.mounet.com.

Currently, users receive mail at [EMAIL PROTECTED] with no problems.

We are gonna build another box to replace the existing mail server running
qmail named qmail.mounet.com  We also gonna be doing e-mail services for
etsu.mounet.com on the same machine.  We have already determined we wont
have the problem of two users trying to use the same login name such as
[EMAIL PROTECTED] and [EMAIL PROTECTED] so that isnt a problem.  I need to
figure out how to get my qmail box setup so our regular users can receive
mail at [EMAIL PROTECTED], and the etsu users can receive mail at
[EMAIL PROTECTED], but not vice versa (if possible).  Also, what would
happen if someone has their e-mail configuration setup to retrieve mail
from qmail.mounet.com and they should be using etsu.mounet.com?  Could that
have any effect on anything?  Ive got it working so that accounts on
qmail.mounet.com can check their POP3 mail fine, but I havent even began
working on the virtual domain part yet.  Will I have to specify a file that
lists what users should receive mail for [EMAIL PROTECTED] and which
should receive for [EMAIL PROTECTED]?  Any help will be very
appreciative.  I've scanned through several of the archives on virtual
domains, but havent really seen a good HOWTO on setting these up for this
situation.  Thanks again!




Hi,


Could some one please explain this to me:

920403544.098213 delivery 317: deferral:
Uh-oh:_.qmail_has_prog_delivery_but_has_x_bit_set._(#4.7.0)/
920403544.098239 status: local 0/10 remote 0/20


It looks kinda worrying!

also, is there a way to be copied on all errors?

Cheers

Peter.


--
gradwell dot com ltd - writing the bits of the web you don't see
online @ http://www.gradwell.com/ mailto:[EMAIL PROTECTED]

"To look back all the time is boring. Excitement lies in tomorrow"






On Wed, Feb 03, 1999 at 07:41:06PM +0000, Peter Gradwell wrote:
> Hi,
> 
> 
> Could some one please explain this to me:
> 
> 920403544.098213 delivery 317: deferral:
> Uh-oh:_.qmail_has_prog_delivery_but_has_x_bit_set._(#4.7.0)/
> 920403544.098239 status: local 0/10 remote 0/20

The message looks pretty straightforward: the .qmail file has the execute bit
set and has a program delivery instruction in it, and qmail doesn't like that.
>From man dot-qmail:

       If .qmail has the execute bit set, it must not contain any
       program lines, mbox lines, or maildir  lines.   If  qmail-
       local  sees  any  such  lines, it will stop and indicate a
       temporary failure.

Why does qmail object to the execute bit being set? I don't know. But if you
want to get rid of the error message, chmod -x the .qmail file.

> It looks kinda worrying!
> 
> also, is there a way to be copied on all errors?

What do you mean?

Chris




- Chris Johnson <[EMAIL PROTECTED]>:

| Why does qmail object to the execute bit being set? I don't know.

Security:  It's meant for .qmail files that might be automatically
edited, for example by a mailing list manager.  Even if an attacker
manages to sneak in a program delivery in the .qmail file, this
feature will stop him from exploiting it.

- Harald




At 09:33 PM 2/3/99 +0100, Harald Hanche-Olsen wrote:
>- Chris Johnson <[EMAIL PROTECTED]>:
>
>| Why does qmail object to the execute bit being set? I don't know.
>
>Security:  It's meant for .qmail files that might be automatically
>edited, for example by a mailing list manager.  Even if an attacker
>manages to sneak in a program delivery in the .qmail file, this
>feature will stop him from exploiting it.

I'm not quite sure I understand the second part of that, but certainly the 
first part about it providing a simple locking mechanism is how it was used 
by qlist.


Regards.





- Mark Delany <[EMAIL PROTECTED]>:

| At 09:33 PM 2/3/99 +0100, Harald Hanche-Olsen wrote:
| >- Chris Johnson <[EMAIL PROTECTED]>:
| >
| >| Why does qmail object to the execute bit being set? I don't know.
| >
| >Security:  It's meant for .qmail files that might be automatically
| >edited, for example by a mailing list manager.  Even if an attacker
| >manages to sneak in a program delivery in the .qmail file, this
| >feature will stop him from exploiting it.
| 
| I'm not quite sure I understand the second part of that, but
| certainly the first part about it providing a simple locking
| mechanism is how it was used by qlist.

No; qlist locked .qmail-list-request in order to avoid several copies
of qlist stomping on the .qmail-list file at the same time.  The man
page further stated:

       qlist automatically sets the execute bit on qmail-list, so
       qmail-local  will  ignore any program or file instructions
       in qmail-list.

The point being that if a user could somehow coerce qlist into putting
the line

|rm -fr *

into .qmail-list, it still would not do any harm (unless the list
owner turned off the execute bit without checking the file).

- Harald




At 22:34 3/02/99 +0100, Harald Hanche-Olsen wrote:
>- Mark Delany <[EMAIL PROTECTED]>:

>| I'm not quite sure I understand the second part of that, but
>| certainly the first part about it providing a simple locking
>| mechanism is how it was used by qlist.
>
>No; qlist locked .qmail-list-request in order to avoid several copies
>of qlist stomping on the .qmail-list file at the same time.  The man
>page further stated:
>
>       qlist automatically sets the execute bit on qmail-list, so
>       qmail-local  will  ignore any program or file instructions
>       in qmail-list.
>
>The point being that if a user could somehow coerce qlist into putting
>the line
>
>|rm -fr *
>
>into .qmail-list, it still would not do any harm (unless the list
>owner turned off the execute bit without checking the file).


Ahh, yes. That'll teach me relying on a knowingly faulty human memory.


Regards.





Hi,

Can some one help me!! I'm dropping mail left right an centre :-(

Im my log I have errors like

920404304.660331 starting delivery 328: msg 321541 to local
[EMAIL PROTECTED]
920404304.660358 status: local 1/10 remote 0/20
920404304.668162 delivery 328: deferral:
Uh-oh:_.qmail_has_prog_delivery_but_has_x_bit_set._(#4.7.0)/
920404304.668188 status: local 0/10 remote 0/20
920404344.670379 starting delivery 329: msg 321542 to local
[EMAIL PROTECTED]
920404344.670405 status: local 1/10 remote 0/20
920404344.679381 delivery 329: deferral:
Uh-oh:_.qmail_has_prog_delivery_but_has_x_bit_set._(#4.7.0)/
920404344.679407 status: local 0/10 remote 0/20
920404424.680526 starting delivery 330: msg 321545 to local
[EMAIL PROTECTED]
920404424.680552 status: local 1/10 remote 0/20
920404424.680566 starting delivery 331: msg 321545 to remote [EMAIL PROTECTED]
920404424.680585 status: local 1/10 remote 1/20
920404424.680957 delivery 331: deferral:
Sorry,_message_has_wrong_owner._(#4.3.5)/
920404424.680979 status: local 1/10 remote 0/20
920404424.681266 delivery 330: deferral:
Sorry,_message_has_wrong_owner._(#4.3.5)/
920404424.681287 status: local 0/10 remote 0/20
920404584.690386 starting delivery 332: msg 321544 to local
[EMAIL PROTECTED]
920404584.690412 status: local 1/10 remote 0/20
920404584.698611 delivery 332: deferral:
Uh-oh:_.qmail_has_prog_delivery_but_has_x_bit_set._(#4.7.0)/
920404584.698637 status: local 0/10 remote 0/20

and when I try to send mail to it, it's returning the error
451 qq Trouble creating files in Queue.

Do you have any ideas ?

Thanks

peter.


--
gradwell dot com ltd - writing the bits of the web you don't see
online @ http://www.gradwell.com/ mailto:[EMAIL PROTECTED]

"To look back all the time is boring. Excitement lies in tomorrow"






- Peter Gradwell <[EMAIL PROTECTED]>:

| Can some one help me!! I'm dropping mail left right an centre :-(

Your queue structure is clearly seriously messed up.

Stop qmail, then move /var/qmail/queue to /var/qmail/badqueue and
reinstall ("make setup check").

Then have a look at the messages in the badqueue directory.  Read the
INTERNALS file, noting among other things that files under the mess
subdirectory must have an inode number equal to their name.  Did you
perhaps violate this by restoring a queue from backup, for example?
If so, messages need renumbering before you can move them back in the
queue.  Also, if queue files had their ownership changed, that must be
fixed.  The mess/*/* files should have owner qmailq, while ones under
info/, local/, and remote/ should be owned by qmails.

You may find it easier to just reinject messages in the queue based on
what is in the info (envelope sender) and local and remote files.  The
qmail-queue man page explains what is needed; what goes to file
descriptor 1 is the concatenation of the info file, then the remote
and local files, with an extra NUL byte appended.

Oh, actually, that would resend messages that were already
delivered.  Try instead the output of

( cat info/$msg remote/$msg local/$msg | tr '\000' '\012'; echo ) |
grep '^[FT]' | tr '\012' '\000'

"Some assembly required."  (No, not assembly *language*.)

The latter approach has the advantage that you can restart the queue
without waiting to stuff messages from the old queue into the new one.

- Harald




Hi guys,

Thanks for your hints

The /var/qmail/bin/ programs had the wrong permissions, though as far as I
can see, the queue structure is ok.

make setup, check worked wonders :-)

That was an unpleasant 2 hours <g>

Cheers

Peter.


--
gradwell dot com ltd - writing the bits of the web you don't see
online @ http://www.gradwell.com/ mailto:[EMAIL PROTECTED]

"To look back all the time is boring. Excitement lies in tomorrow"






I read the QMTP protocol document and there doesn't seem to be anything
that would indicate VERP is done on messages. In fact doing this could
break things if the envelope sender address couldn't handle VERP.

Maybe QMTP should be extended in a way that allows for VERP without having
to restransmit the message body more than once. Perhaps more than one
sender address could be sent. Sender and recipient addresses would be
pair up until one list or the other was exhausted and the last one from
the shorter list would be paired with items at the end of the longer list.





Bruno Wolff III wrote/schrieb/scribsit:
> Maybe QMTP should be extended in a way that allows for VERP without
> having to restransmit the message body more than once. Perhaps more than
> one sender address could be sent.

See QMAIL EXTENSIONS in addresses.5.

Stefan





On Wed, Feb 03, 1999 at 10:25:37PM +0100,
  Stefan Paletta <[EMAIL PROTECTED]> wrote:
> 
> Bruno Wolff III wrote/schrieb/scribsit:
> > Maybe QMTP should be extended in a way that allows for VERP without
> > having to restransmit the message body more than once. Perhaps more than
> > one sender address could be sent.
> 
> See QMAIL EXTENSIONS in addresses.5.
> 
> Stefan

The stuff there doesn't seem to apply at the point the qmtp connection is
being processed. Another way to extend QMTP would be to have sender addresses
that end with -@[] expanded with VERP information. It looks like qmail
would have to be changed to delay the expansion of VERPs from qmail-send
until qmail-remote, since the protocol by which the message will be
transmitted won't be known until then.





Bruno Wolff III wrote/schrieb/scribsit:
>   Stefan Paletta <[EMAIL PROTECTED]> wrote:
>> See QMAIL EXTENSIONS in addresses.5.

> The stuff there doesn't seem to apply at the point the qmtp connection
> is being processed.

This problem is on the sending end, since qmail itself cannot do
multiple rcpt deliveries; anyone is free to write a QMTP client that
leaves VERP expansion to the server.

> Another way to extend QMTP would be to have sender
> addresses that end with -@[] expanded with VERP information. 

True - this would be useful if qmail at one point did multiple rcpt
deliveries and it would be necessary if other MTAs supported QMTP then.

> It looks like qmail would have to be changed to delay the expansion of
> VERPs from qmail-send until qmail-remote, since the protocol by which
> the message will be transmitted won't be known until then.

Again, this has been beaten to death in the multiple rcpt
discussions^Wflame-wars.

Any takers for an ESMTP server-sided VERP expansion extension draft? ;-)

Stefan





This is really directed more toward Paul Gregg <[EMAIL PROTECTED]>, but I
thought the whole list might get some benefit from my mistakes.

I'm using your checkpoppasswd program derived from the checkpasswd of
Jedi/Sector One. I've modified it by putting more intuitive messages into
the syslog messages and got it working, authenticating users at one point,
but now it's failing with the log message "Couldn't setgid (888)." I'm
running qmail-pop3d.init with the uid and gid of the qmaild user (81 and 80
respectively. It was originally root, but I thought that might be a security
hazard and changed it to the same uid/gid of the other qmail servers. Is
there a valid reason for having qmail-pop3d run as root? Is it because
qmail-pop3d has to be able to delete files owned by others? I put qmaild into
the popuser group (888) but it still failed at the same point.

Anyone, please advise.
--
Matt Garrett, Network Engineer
Superior Open Systems
[EMAIL PROTECTED]





On Wed, Feb 03, 1999 at 04:29:57PM +0000, Matt Garrett wrote:
> This is really directed more toward Paul Gregg <[EMAIL PROTECTED]>, but I
> thought the whole list might get some benefit from my mistakes.
> 
> I'm using your checkpoppasswd program derived from the checkpasswd of
> Jedi/Sector One. I've modified it by putting more intuitive messages into
> the syslog messages and got it working, authenticating users at one point,
> but now it's failing with the log message "Couldn't setgid (888)." I'm
> running qmail-pop3d.init with the uid and gid of the qmaild user (81 and 80
> respectively. It was originally root, but I thought that might be a security
> hazard and changed it to the same uid/gid of the other qmail servers. Is
> there a valid reason for having qmail-pop3d run as root? Is it because
> qmail-pop3d has to be able to delete files owned by others? I put qmaild into
> the popuser group (888) but it still failed at the same point.

qmail-pop3d doesn't run as root--it runs with the uid/gid of the user who owns
the Maildir. Since that isn't known beforehand, the process that execs it
(checkpoppasswd in your case) has to be running as root; otherwise it couldn't
setuid/setgid to an arbitrary user/group.

If all of your mailboxes are owned by the same uid, you could probably rig
things up so that everything runs with the popuser uid/gid.

Chris




I've looked through the FAQ and and also searched through the archived
mailing list but couldn't find any answers to what happened to the "mail
-v" (verbose) command. I know that the mailx command is specific to
sendmail and wouldn't be surprised if it won't work. I assume that there
either is a work around, or it just won't work. I will research this but
would appreciate it if some would repond if they know the answer.

Thanks.

--vt




- Victor Tavares <[EMAIL PROTECTED]>:

| I've looked through the FAQ and and also searched through the
| archived mailing list but couldn't find any answers to what happened
| to the "mail -v" (verbose) command.

AFAIK, all it does is pass the -v flag to sendmail.  qmail's sendmail
clone just ignores -v, so mail should go through just fine, but it
still won't be verbose of course.  Note that in qmail's case,
verbosity would not gain anything anyhow, as all that happens is that
the mail is injected into the queue.  The rest is done by the daemon,
backstage.

- Harald




Hi,

I've setup qmail 1.03 with the anti UCE path from Sam, but I'm seeing
some strange things:

when somebody from the external word sends a mail to a nonexistent user,

he gets a mail back
with failure notice etc, but in the notice it isn't said why it failed.
But I can see the reason in the logfiles. Does this have something todo
with the remote client or remote mailserver?
When I try the same, it's ok for my hotmail account, and I see the
failure reason.

Franky



Reply via email to