qmail Digest 19 Aug 1999 10:00:01 -0000 Issue 733

Topics (messages 29153 through 29198):

Can not get with Netscape or Outlook.
        29153 by: "Thomas M. Sasala" <[EMAIL PROTECTED]>
        29162 by: [EMAIL PROTECTED]
        29170 by: [EMAIL PROTECTED]

Relaying large attachments
        29154 by: Chris McCarthy <[EMAIL PROTECTED]>
        29160 by: "Sam" <[EMAIL PROTECTED]>
        29164 by: "Adam D . McKenna" <[EMAIL PROTECTED]>
        29166 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
        29169 by: Dave Sill <[EMAIL PROTECTED]>
        29171 by: Chris McCarthy <[EMAIL PROTECTED]>
        29180 by: "Fred Lindberg" <[EMAIL PROTECTED]>
        29185 by: "Adam D . McKenna" <[EMAIL PROTECTED]>

Lots and lots of qmail-queue's
        29155 by: Martin Ouwehand <[EMAIL PROTECTED]>
        29191 by: Aaron Nabil <[EMAIL PROTECTED]>

sqwebmail
        29156 by: Paul Farber <[EMAIL PROTECTED]>

ORBS and other relay blockers
        29157 by: Bruno Wolff III <[EMAIL PROTECTED]>
        29196 by: John R Levine <[EMAIL PROTECTED]>

the qmail book!
        29158 by: Magnus Bodin <[EMAIL PROTECTED]>

User Name length restriction
        29159 by: Juan Carlos Castro y Castro <[EMAIL PROTECTED]>
        29165 by: User JAMES <[EMAIL PROTECTED]>

When is the next revision to Qmail due out...
        29161 by: Jim Beam <[EMAIL PROTECTED]>
        29167 by: Jack Daniels <[EMAIL PROTECTED]>
        29186 by: Glen Fiddich <[EMAIL PROTECTED]>

simple relaying (I thought)
        29163 by: "Denis Voitenko" <[EMAIL PROTECTED]>
        29168 by: Chris Johnson <[EMAIL PROTECTED]>
        29183 by: Chris Santerre <[EMAIL PROTECTED]>

qmtp and smtp coexisting
        29172 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
        29184 by: "Fred Lindberg" <[EMAIL PROTECTED]>

queue not preprocessing
        29173 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
        29174 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
        29175 by: Chris Johnson <[EMAIL PROTECTED]>
        29176 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
        29177 by: Dave Sill <[EMAIL PROTECTED]>
        29178 by: Russell Nelson <[EMAIL PROTECTED]>
        29179 by: "Daniluk, Cris" <[EMAIL PROTECTED]>

question on big-todo patch
        29181 by: "Lyndon Griffin" <[EMAIL PROTECTED]>
        29182 by: "Lyndon Griffin" <[EMAIL PROTECTED]>
        29187 by: "Fred Lindberg" <[EMAIL PROTECTED]>

Virtualusers in subdirectories?
        29188 by: Marthe Nes�en Gangfl�t <[EMAIL PROTECTED]>
        29189 by: Dave Sill <[EMAIL PROTECTED]>

Modifying sent mail
        29190 by: "Jose de Leon" <[EMAIL PROTECTED]>
        29192 by: "Sam" <[EMAIL PROTECTED]>

humble suggestion from a confused boy
        29193 by: Mate Wierdl <[EMAIL PROTECTED]>
        29194 by: Bruce Guenter <[EMAIL PROTECTED]>

Extra copies of mail
        29195 by: "Jon Lur�s" <[EMAIL PROTECTED]>

former user
        29197 by: aw <[EMAIL PROTECTED]>
        29198 by: "Klaus Wissmann" <[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]


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


Dan,
        I have you tried to manually log in to the pop3 server?
Try this:

        You                    The Server
        -----------------     -------------
        telent <host> 110  --> +OK <xxxx@host>
        user <name>        --> +OK
        pass <passwd>      --> +OK
        list               --> {output depends on your mail}
        quit               --> +OK

        See what happens.

        -T
> 
> I do have the spool files setup correctly.  They are also setup the same on both 
>boxes.  I am really stumped. :(
> 
> Dan

-- 
+-------------------------------------------------------------------+
+  Thomas M. Sasala, Electrical Engineer       [EMAIL PROTECTED]       +
+  MRJ Technology Solutions                    http://www.mrj.com   +
+  10461 White Granite Drive, Suite 102        (W)(703)277-1714     +
+  Oakton, VA   22124                          (F)(703)277-1702     +
+-------------------------------------------------------------------+




Thanks for the help.  Got it working.

Let's just say that the solution was embarrassing.

:P

Dan





OK.   For the laugh at newbie sake. :)

I performed a default server install of Mandrake 6.0.  Guess what does not
get installed?  You probably know.



IMAP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



HEE HEE HEE HEE HEE.

Like I said, embarrassing.

:)

Dan






My company has 2 qmail servers, one is a dialup, the other is online
permanently in another office.
When a user in the dialup office sends an email with a large attachment
to a large number of recipients, is it possible to configure the dialup
qmail server to send one copy to the other qmail server to relay, so
that the dialup line is not being used to transfer the same attachment
to all recipients ?


..Chris.





Chris McCarthy writes:

> 
> My company has 2 qmail servers, one is a dialup, the other is online
> permanently in another office.
> When a user in the dialup office sends an email with a large attachment
> to a large number of recipients, is it possible to configure the dialup
> qmail server to send one copy to the other qmail server to relay, so
> that the dialup line is not being used to transfer the same attachment
> to all recipients ?

The short answer is no.  With a lot of pain, you can probably find some way
to hack around it, like dumping all mail into a Maildir, detecting
duplicate messages and combining them together, then unloading the combined
messages into the relay when the line comes up.

If this represents your typical mail traffic, Qmail isn't the right mail
server for you.


-- 
Sam





On Wed, Aug 18, 1999 at 04:26:19PM +0000, Sam wrote:
> Chris McCarthy writes:
> 
> > 
> > My company has 2 qmail servers, one is a dialup, the other is online
> > permanently in another office.
> > When a user in the dialup office sends an email with a large attachment
> > to a large number of recipients, is it possible to configure the dialup
> > qmail server to send one copy to the other qmail server to relay, so
> > that the dialup line is not being used to transfer the same attachment
> > to all recipients ?
> 
> The short answer is no.  With a lot of pain, you can probably find some way
> to hack around it, like dumping all mail into a Maildir, detecting
> duplicate messages and combining them together, then unloading the combined
> messages into the relay when the line comes up.
> 
> If this represents your typical mail traffic, Qmail isn't the right mail
> server for you.

What about using qmtp/qmqp?  Wouldn't this accomplish what he needs?

--Adam

> 
> 
> -- 
> Sam
> 




Why not have the user send via an alternate account that uses the smtp
server of the main office directly that way it is only sent once. This is
very easy to do in Outlook, Outlook Express, Eudora, Netscape, etc. and it
requires virtually no effort on your part.

Cris Daniluk
MicroStrategy

> -----Original Message-----
> From: Chris McCarthy [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 18, 1999 1:58 PM
> To: [EMAIL PROTECTED]
> Subject: Relaying large attachments
> 
> 
> 
> My company has 2 qmail servers, one is a dialup, the other is online
> permanently in another office.
> When a user in the dialup office sends an email with a large 
> attachment
> to a large number of recipients, is it possible to configure 
> the dialup
> qmail server to send one copy to the other qmail server to relay, so
> that the dialup line is not being used to transfer the same attachment
> to all recipients ?
> 
> 
> ..Chris.
> 
> 




"Adam D . McKenna" <[EMAIL PROTECTED]> wrote:
>
>What about using qmtp/qmqp?  Wouldn't this accomplish what he needs?

No, SMTP already has a mechanism to handle this (multiple RCPT's), and
QMTP doesn't add anything there. The "problem" is that qmail doesn't
try to minimize bandwidth by using multiple RCPT's [1]. Also, I
believe he said he's unlikely to get the server to run anything
special for him.

-Dave

[1] http://Web.InfoAve.Net/~dsill/lwq.html#multi-rcpt




I have thought of that, the disadvantage is that it takes longer to upload.
Sending to the server on the LAN takes hardly no time, the subsequent
uploading from server to server is of course transparent to the user.
I guess I'll just leave things as they are and suffer an occasional drop in
bandwidth.

A possible workaround (on a slightly different topic)... is it possible to
prioritize ppp traffic so that SMTP traffic is given a lower priority than web
browsing etc.  Taking this even further, is it possible to get qmail to
prioritize email without attachments ?

Thanks for the help,
..Chris.

"Daniluk, Cris" wrote:

> Why not have the user send via an alternate account that uses the smtp
> server of the main office directly that way it is only sent once. This is
> very easy to do in Outlook, Outlook Express, Eudora, Netscape, etc. and it
> requires virtually no effort on your part.





On Wed, 18 Aug 1999 12:43:25 -0400 (EDT), Dave Sill wrote:

>No, SMTP already has a mechanism to handle this (multiple RCPT's), and
>QMTP doesn't add anything there. The "problem" is that qmail doesn't
>try to minimize bandwidth by using multiple RCPT's [1]. Also, I
>believe he said he's unlikely to get the server to run anything
>special for him.

QMQP sends the message once with all target addresses. QMTP has the
same provisions, but of course it depends on the implementation of the
client.

To use qmail-qmqpc/d over a dialup line, you may have to change the
timeouts (probably mainly timeoutconnect). Especially the qmpcd write
timeout is too short and will over a poor connection lead to
duplications (d times out on writing status to c but uses the message;
c doesn't get status info and resends the message).

If the dialing-up MTA is low use, you could also use sendmail here.
Postfix is another alternative which should deal with high volume much
better than sendmail.

It would be great to have a qmail-qmtpc that replaces qmail-send of a
normal installation, or even better, a qmail-send that uses qmail-local
for local deliveries, but a qmail-qmtpc for remote (one per message;
not one per recipient). Keeping fingers crossed for qmail-2.0 ;-)


-Sincerely, Fred

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






On Wed, Aug 18, 1999 at 12:43:25PM -0400, Dave Sill wrote:
> "Adam D . McKenna" <[EMAIL PROTECTED]> wrote:
> >
> >What about using qmtp/qmqp?  Wouldn't this accomplish what he needs?
> 
> No, SMTP already has a mechanism to handle this (multiple RCPT's), and
> QMTP doesn't add anything there. The "problem" is that qmail doesn't
> try to minimize bandwidth by using multiple RCPT's [1]. Also, I
> believe he said he's unlikely to get the server to run anything
> special for him.

I thought that qmtp supported multiple RCPT's..  Anyway..  I thought he said
that he was in control of both servers.  my bad.

--Adam





Aaron Nabil <[EMAIL PROTECTED]> writes:

] >Has anybody seen this: from time to time, a whole bunch of qmail-queue's
] >will accumulate (I'd say up to ~400), apparently doing nothing (ps shows
] >that most of them have the same WCHAN, but not all of them). Most of
] >them have 1 as PPID, a few still have qmail-smtpd as parent.
] 
] Are they all in TIME_WAIT?  It's probably one machine.

It sure is. As to the TIME_WAIT, this doesn't seem to be a problem
(a "netstat -an" doesn't show to many sockets, in whatever state).

] Look in the logs (or use netstat or lsof) to get the IP address of the
] machine.
] 
] Use my recordio patch to record dialog just for that host.

Thanks, it was very useful.

] I bet you'll find qmail is dropping the connection with the "bare LF" 
] message.  I've previously given my point of view on qmail's non-RFC 
] compliance on the list before, find that message, apply the patch.

You're right about the "bare LF" message. About your patch: if you mean
the one where you just comment out those "if (ch == '\n') straynewline();"
lines, I'm afraid that the exchange following your proposal convinced me
that this isn't the right solution.

BUT, I'm also convinced that the present situation isn't satisfactory. It is
of no comfort to me that the client is the culprit by not following some RFC
if my server is on its knees ! So what can we do to avoid this ? One way
would be not to _exit() in straynewline() but taking care of the state
we're in is barely within the limit of my window of understanding of the
source code. What do you think of this ?:

 ==============================================================================
--- qmail-smtpd.c.orig  Mon Jun 15 12:53:16 1998
+++ qmail-smtpd.c       Wed Aug 18 15:49:57 1999
@@ -47,7 +47,6 @@
 void die_nomem() { out("421 out of memory (#4.3.0)\r\n"); flush(); _exit(1); }
 void die_control() { out("421 unable to read controls (#4.3.0)\r\n"); flush(); 
_exit(1); }
 void die_ipme() { out("421 unable to figure out my IP addresses (#4.3.0)\r\n"); 
flush(); _exit(1); }
-void straynewline() { out("451 See http://pobox.com/~djb/docs/smtplf.html.\r\n"); 
flush(); _exit(1); }
 
 void err_bmf() { out("553 sorry, your envelope sender is in my badmailfrom list 
(#5.7.1)\r\n"); }
 void err_nogateway() { out("553 sorry, that domain isn't in my list of allowed 
rcpthosts (#5.7.1)\r\n"); }
@@ -290,6 +289,8 @@
   qmail_put(&qqt,ch,1);
 }
 
+int straynewline;
+
 void blast(hops)
 int *hops;
 {
@@ -322,17 +323,17 @@
     }
     switch(state) {
       case 0:
-        if (ch == '\n') straynewline();
+        if (ch == '\n') { straynewline = 1; return; }
         if (ch == '\r') { state = 4; continue; }
         break;
       case 1: /* \r\n */
-        if (ch == '\n') straynewline();
+        if (ch == '\n') { straynewline = 1; return; }
         if (ch == '.') { state = 2; continue; }
         if (ch == '\r') { state = 4; continue; }
         state = 0;
         break;
       case 2: /* \r\n + . */
-        if (ch == '\n') straynewline();
+        if (ch == '\n') { straynewline = 1; return; }
         if (ch == '\r') { state = 3; continue; }
         state = 0;
         break;
@@ -379,7 +380,9 @@
   out("354 go ahead\r\n");
  
   received(&qqt,"SMTP",local,remoteip,remotehost,remoteinfo,fakehelo);
+  straynewline = 0;
   blast(&hops);
+  if (straynewline) qmail_fail(&qqt);
   hops = (hops >= MAXHOPS);
   if (hops) qmail_fail(&qqt);
   qmail_from(&qqt,mailfrom.s);
@@ -387,6 +390,7 @@
  
   qqx = qmail_close(&qqt);
   if (!*qqx) { acceptmessage(qp); return; }
+  if (straynewline) { out("451 See http://pobox.com/~djb/docs/smtplf.html.\r\n"); 
+return; }
   if (hops) { out("554 too many hops, this message is looping (#5.4.6)\r\n"); return; 
}
   if (databytes) if (!bytestooverflow) { out("552 sorry, that message size exceeds my 
databytes limit (#5.3.4)\r\n"); return; }
   if (*qqx == 'D') out("554 "); else out("451 ");

 ==============================================================================

I said I would not invoke any RFC in vain, but I can't resist :-), I think
this patch is in line with RFC 821, page 26:

     The receiver should not close the transmission channel until
     it receives and replies to a QUIT command (even if there was an
     error).

Another solution for me would be to understand (and fix) why all these
qmail-queue stay around when their father _exit()'s. For example,
shouldn't straynewline() do some clean-up before _exit()'ing ?

Thanks for any advice...


--
  | ~~~~~~~~ Martin Ouwehand ~ Swiss Federal Institute of Technology ~ Lausanne
__|_________ Email/PGP: http://slwww.epfl.ch/SIC/SL/info/Martin.html __________
Educar es vincular la ciencia y la ternura                         [Jos� Mart�]





Martin Ouwehand writes...
>Aaron Nabil <[EMAIL PROTECTED]> writes:
>
>] >Has anybody seen this: from time to time, a whole bunch of qmail-queue's
>] >will accumulate (I'd say up to ~400), apparently doing nothing (ps shows
>] >that most of them have the same WCHAN, but not all of them). Most of
>] >them have 1 as PPID, a few still have qmail-smtpd as parent.
>] 
>] Are they all in TIME_WAIT?  It's probably one machine.
>
>It sure is. As to the TIME_WAIT, this doesn't seem to be a problem
>(a "netstat -an" doesn't show to many sockets, in whatever state).

On mine the connections would hang around 2*MSL, but this doesn't
seem to be a problem in your implementation, or you've tuned your
MSL down, sometimes people do that.

>
>] Look in the logs (or use netstat or lsof) to get the IP address of the
>] machine.
>] 
>] Use my recordio patch to record dialog just for that host.
>
>Thanks, it was very useful.

You are welcome.

>
>] I bet you'll find qmail is dropping the connection with the "bare LF" 
>] message.  I've previously given my point of view on qmail's non-RFC 
>] compliance on the list before, find that message, apply the patch.
>
>You're right about the "bare LF" message. About your patch: if you mean
>the one where you just comment out those "if (ch == '\n') straynewline();"
>lines, I'm afraid that the exchange following your proposal convinced me
>that this isn't the right solution.

Yikes!  I stopped the dialog on the qmail list beacuse it's simply wasn't 
productive, not beacause I didn't have more to say.  The author's position
on the subject seems political, not technical, and the qmail list is the
wrong place for a politcal debate.

RFC-822 allows bare line feeds.  RFC-821 prohibits termination before
quit.  RFC 1652 requires 8BITMIME to supress local conversions and
pass data unmodified (although RFC's dealing with the MIME _body_ may
disallow bare LF's, RFC 1652 defines how the MTA must handle an 8BITMIME 
envelope).  There is no debate on these issues.  It's all in black
and white, and qmail violates all three.

That some _draft_ version of a future RFC (that may or may not ever become
an internet "standard") disallows bare LFs is a very flimsy excuse for a
MTA to refuse to interoperate with a MTA that _is_ following RFC-822
_as published_.  I fully intended to make sure the the working group 
understands that people are using the _draft_ as an excuse not to 
interoperate with RFC-822 MTA's, and that some language needs to be
inserted about interoperability.  It's perfectly OK for a 822bis MTA
to not generate bare LF's itself (in fact, it shouldn't), but there 
are always going to be RFC-822 MTA's out there, and you need to 
interoperate with them.

I _am_ going to take it up with the 822bis working group, but plowing 
through the existing 5000 messages is taking a while, and there has been 
some substantial discussion on the subject before.  It may be a couple
weeks.

>BUT, I'm also convinced that the present situation isn't satisfactory. It is
>of no comfort to me that the client is the culprit by not following some RFC
>if my server is on its knees ! So what can we do to avoid this ? One way
>would be not to _exit() in straynewline() but taking care of the state
>we're in is barely within the limit of my window of understanding of the
>source code. What do you think of this ?:

Well, I guess I've already made my opinion about bare LF's known, but
if your intention is still to disallow them but fix the "terminate
before quit" problem, it seems like a reasonable approach.  I'm not
sure using a 451 error is desirable, unless your back-up MX handler 
is sendmail it's just going to re-queue and fail again.  Might as well
use 551 and be done with it.

> . . .

>Another solution for me would be to understand (and fix) why all these
>qmail-queue stay around when their father _exit()'s. For example,
>shouldn't straynewline() do some clean-up before _exit()'ing ?
>
>Thanks for any advice...

I'm just guessing, but there might be some kind of deadlock or
subobtimal signal handling going on with the child.  Failing anything
else, I'd imagine the qmail-queue would get a SIGPIPE when the 
qmail-smtpd dies, but purhaps it's getting masked, and you are getting
zombification.  Dunno, would have to look into it.


-- 
Aaron Nabil




Hello all... 

Trying to get sqwebmail up and running an a RH 5.2 qmail 1.03 system.
This is one case where there is no M to RTF.

The sqwebmail list seems dead, or it didn't take my reply to subscribe...
anyone use this front end can give some tips?

Thanks

Paul D. Farber II
Farber Technology
Ph. 570-628-5303
Fax 570-628-5545
[EMAIL PROTECTED]





On Tue, Aug 17, 1999 at 11:38:22PM -0400,
  John R Levine <[EMAIL PROTECTED]> wrote:
> 
> ORBS probes come from a single IP address so it's easy just to block
> them with tcpserver rules.  While you're at it, you might as well
> block some of the other SMTP relay scanners:

Before you do, you should make sure blocking them isn't going to get
you put on their lists.

Also if you don't mind the occasional small amount of traffic, having
ORBS or one of the others tell you that your mail server is open, is
better than having abused by spammers when they find it.




>> ORBS probes come from a single IP address so it's easy just to block
>> them with tcpserver rules.  While you're at it, you might as well
>> block some of the other SMTP relay scanners:
>
>Before you do, you should make sure blocking them isn't going to get
>you put on their lists.

Unless you do something else to annoy them, you won't.  It hardly matters,
when I was in ORBS the amount of mail that bounced was infinitesimal.
The only blocking system that's widely used is the RBL.

>Also if you don't mind the occasional small amount of traffic, having
>ORBS or one of the others tell you that your mail server is open, is
>better than having abused by spammers when they find it.

My mail server isn't open, and when somone starts rattling each of the
100 virtual IPs on the machine and sending 18 probe messages per IP,
it gets really old really fast.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4  2D AC 1E 9E A6 36 A3 47 





While we are waiting for this nugget, 
has anyone looked at this more general one?

"Programming Internet Email"

http://www.oreilly.com/catalog/progintemail/

By David Wood
1st Edition August 1999
1-56592-479-7, Order Number: 4797
378 pages, $34.95

Internet mail protocols have become not just an enabling technology for 
messaging, but a programming interface on top of which core applications 
are built. This book is an essential guide and reference for programmers
building applications on top of email capabilities and for power users
trying to get under the hood of their own email systems.


/magnus

-- 
"MOST USELESS site of the year 1998" --> http://x42.com/urlcalc/





Samar Vijay wrote:

> Is there any way to increase the username length to more that 8
> characters
> that freeBSD imposes?
> I have moved to Qmail recently and I have a few users who would like
> to use
> their previous
> mail address.

Have everybody have an alias. You can even have the Unix file names all
like this: u0000001, u0000002, .... u0018604, ... and each of these will
have a corresponding file in ~alias. Like:

/var/qmail/alias> cat .qmail-monica:lewinsky
&[EMAIL PROTECTED]

would define the e-mail for [EMAIL PROTECTED] (remember to
translate dots to colons). With a little work you may even have this as
an automated user creation process (an administrative web page, for
instance) which picks the next available number from a file and asks for
a Real Name (for finger) and an E-Mail Name.






On Tue, 17 Aug 1999, Russell Nelson wrote:

> Samar Vijay writes:
>  > Is there any way to increase the username length to more that 8
>  > characters that freeBSD imposes?  I have moved to Qmail recently
>  > and I have a few users who would like to use their previous mail
>  > address.
> 
> I think, Samar, that you're failing to make a distinction between a
> username and an email address.  Unix doesn't help you make that
> distinction, since both concepts are merged into one.  However, there
> is no reason why that should be so.

<snip> lots of good advice by Russell

What's more, recent versions of FreeBSD make no such restricition...





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just curious as to when there might be a next version (v1.4 perhaps?) of
qMail available?

James Beam                                         o(713) 952-2800
[EMAIL PROTECTED]                                f(713) 952-2899
}------------------------------------<>---------------------------------
--------{
Entech Information Services           System Administrator
PDQ.net                                               Special Projects


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>

iQA/AwUBN7rfGGQ118V4zeg8EQJyjgCgpW3Tlw6gTk/v2RqUx4MIvwiRDDcAoOBg
/EPUjolKLYaJFeAGiSlMvxMY
=E3q5
-----END PGP SIGNATURE-----




Jim Beam <[EMAIL PROTECTED]> wrote:

>Just curious as to when there might be a next version (v1.4 perhaps?) of
>qMail available?

There's no telling, really. I don't expect another 1.x version,
though. See also:

    http://Web.InfoAve.Net/~dsill/lwq.html#history

which includes a pointer to Dan's "future of qmail" page.

-Dave




Dan is supposedly working on qmail 2.0 right now.

--Adam

On Wed, Aug 18, 1999 at 12:38:53PM -0400, Jack Daniels wrote:
> Jim Beam <[EMAIL PROTECTED]> wrote:
> 
> >Just curious as to when there might be a next version (v1.4 perhaps?) of
> >qMail available?
> 
> There's no telling, really. I don't expect another 1.x version,
> though. See also:
> 
>     http://Web.InfoAve.Net/~dsill/lwq.html#history
> 
> which includes a pointer to Dan's "future of qmail" page.
> 
> -Dave
> 




Well, I think my situation is as simple as it gets yet I have spent over an
hour already trying to fix it. Here's the deal. There is a 16 PC LAN with
Win boxes and a Linux with Qmail. While local mail works fine, Qmail does
not deliver outside the network. I have added

192.168.0.

into the /var/qmail/control/rcpthosts and it still did not change anything.
What should I do to enable relaying? I thought that's what
http://www.palomine.net/qmail/relaying.html says but it seems I got it
wrong. Help me out.





On Wed, Aug 18, 1999 at 12:32:58PM -0400, Denis Voitenko wrote:
> Well, I think my situation is as simple as it gets yet I have spent over an
> hour already trying to fix it. Here's the deal. There is a 16 PC LAN with
> Win boxes and a Linux with Qmail. While local mail works fine, Qmail does
> not deliver outside the network. I have added
> 
> 192.168.0.
> 
> into the /var/qmail/control/rcpthosts and it still did not change anything.
> What should I do to enable relaying? I thought that's what
> http://www.palomine.net/qmail/relaying.html says but it seems I got it
> wrong. Help me out.

It says nothing even remotely resembling that. There's a link on that page that
directs you to http://www.palomine.net/qmail/selectiverelay.html. Read that and
you should be able to get your relaying to work.

Chris




I use sendmail, but I believe you have to edit your hosts.allow and ip.allow files. Check the "life with qmail" web page. It helped GREATLY when I was going to use qmail.
 

Denis Voitenko wrote:

Well, I think my situation is as simple as it gets yet I have spent over an
hour already trying to fix it. Here's the deal. There is a 16 PC LAN with
Win boxes and a Linux with Qmail. While local mail works fine, Qmail does
not deliver outside the network. I have added

192.168.0.

into the /var/qmail/control/rcpthosts and it still did not change anything.
What should I do to enable relaying? I thought that's what
http://www.palomine.net/qmail/relaying.html says but it seems I got it
wrong. Help me out.

begin:vcard 
n:Santerre;Chris
tel;pager:(401)452-6449
tel;work:(401)453-4455 ext.109
x-mozilla-html:TRUE
url:www.paginc.com
org:Property Advisory Group
version:2.1
email;internet:[EMAIL PROTECTED]
title:IT Manager
note:Study the history of Bill Gates, then you will want to buy Linux!
adr;quoted-printable:;;4 Cathedral Square =0D=0ASuite 1G=0D=0A;Providence;RI;02903;USA
fn:Chris
end:vcard




We want to speed the time it takes to inject mail into the qmail queue.
Currently with smtp we can only inject ~500 messages per second. To speed
this up, based on the recommendation of many on the list, I want to
implement QMTP. Will the messages queued via QMTP be stored identically to
those queued via SMTP? The messages will be received from the machine that
generates the mails via QMTP, but it will still need to send via SMTP.

Also, I know this thread has come up before, but what are the ramifications
of bypassing the concurrencyremote limit of 255? This concurrency limit
prevents us from being able to fully utilize 100mbit per network card in the
machines. Running more qmails doesn't seem to be the most logical decision
because we're already running 4 on the machine as it is (1 per nic). What
would the damages by of doubling this hard limit?

Cris Daniluk
Digital Services Network, Inc.





On Wed, 18 Aug 1999 13:21:52 -0400, Daniluk, Cris wrote:

>We want to speed the time it takes to inject mail into the qmail queue.
>Currently with smtp we can only inject ~500 messages per second. To speed
>this up, based on the recommendation of many on the list, I want to
>implement QMTP. Will the messages queued via QMTP be stored identically to
>those queued via SMTP? The messages will be received from the machine that
>generates the mails via QMTP, but it will still need to send via SMTP.

Yes, stored identically.

Look at qmail-qmqpc/qmqpd instead. If you have a good network (local
hosts, on phone lines, no sporadic interruptions between the hosts)
QMQP is excellent and all the programming has already been done for
you.

>Also, I know this thread has come up before, but what are the ramifications
>of bypassing the concurrencyremote limit of 255? This concurrency limit
>prevents us from being able to fully utilize 100mbit per network card in the
>machines. Running more qmails doesn't seem to be the most logical decision
>because we're already running 4 on the machine as it is (1 per nic). What
>would the damages by of doubling this hard limit?

We use P133/64MB/SCSI machines. Increasing concurrency from 255 to 500
gets a 60% increase in performance for lists with 15000 or so
recipients. It's not better since the box becomes processor/disk
limited. There is no difference in performance when concurrency is <
255, i.e. no penalty.

For your hardware, I'd expect a larger increase in performance up to
considerably higher performances (note that kernel 2.2.5 doesn't do it,
unless you have the ac>=3 patches. Don't know if later kernels support
this (earlier ones have a 1024 limit per process). What would be
interesting to know is the difference (assuming queues are on the same
drive) or 4 qmail installations of 250 each vs one with a concurrecy of
1000.


-Sincerely, Fred

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






I've noticed a couple times that qmail will stop preprocessing messages and
the queue will have say a thousand messages, but 900 of them will not yet be
preprocessed. Giving an ALRM to qmail-send does not seem to make a
difference. Is there anything that would trigger this? It's certainly got
enough resources of every kind at its disposal...

Cris Daniluk
MicroStrategy




One vital thing I forgot to mention is that after 20-30 minutes or so
they'll all get processed in a matter of seconds. This is less than
desireable because of the fact that these messages are alerts and therefore
need to be delivered as fast as humanly possible (which is why we use qmail!
:)

Cris

> -----Original Message-----
> From: Daniluk, Cris [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 18, 1999 6:29 PM
> To: QMail (E-mail)
> Subject: queue not preprocessing
> 
> 
> I've noticed a couple times that qmail will stop 
> preprocessing messages and
> the queue will have say a thousand messages, but 900 of them 
> will not yet be
> preprocessed. Giving an ALRM to qmail-send does not seem to make a
> difference. Is there anything that would trigger this? It's 
> certainly got
> enough resources of every kind at its disposal...
> 
> Cris Daniluk
> MicroStrategy
> 




On Wed, Aug 18, 1999 at 01:31:54PM -0400, Daniluk, Cris wrote:
> One vital thing I forgot to mention is that after 20-30 minutes or so they'll
> all get processed in a matter of seconds. This is less than desireable
> because of the fact that these messages are alerts and therefore need to be
> delivered as fast as humanly possible (which is why we use qmail!  :)

Check the permissions on /var/qmail/queue/lock/trigger. They should look like
this:

prw--w--w-  1 qmails  qmail     0 Aug 18 13:35 trigger

Chris

> 
> Cris
> 
> > -----Original Message-----
> > From: Daniluk, Cris [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 18, 1999 6:29 PM
> > To: QMail (E-mail)
> > Subject: queue not preprocessing
> > 
> > 
> > I've noticed a couple times that qmail will stop 
> > preprocessing messages and
> > the queue will have say a thousand messages, but 900 of them 
> > will not yet be
> > preprocessed. Giving an ALRM to qmail-send does not seem to make a
> > difference. Is there anything that would trigger this? It's 
> > certainly got
> > enough resources of every kind at its disposal...
> > 
> > Cris Daniluk
> > MicroStrategy
> > 




It is actually prw--w---... is this a prob?


> -----Original Message-----
> From: Chris Johnson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 18, 1999 6:37 PM
> To: Daniluk, Cris
> Cc: 'QMail (E-mail)'
> Subject: Re: queue not preprocessing
> 
> 
> On Wed, Aug 18, 1999 at 01:31:54PM -0400, Daniluk, Cris wrote:
> > One vital thing I forgot to mention is that after 20-30 
> minutes or so they'll
> > all get processed in a matter of seconds. This is less than 
> desireable
> > because of the fact that these messages are alerts and 
> therefore need to be
> > delivered as fast as humanly possible (which is why we use 
> qmail!  :)
> 
> Check the permissions on /var/qmail/queue/lock/trigger. They 
> should look like
> this:
> 
> prw--w--w-  1 qmails  qmail     0 Aug 18 13:35 trigger
> 
> Chris
> 
> > 
> > Cris
> > 
> > > -----Original Message-----
> > > From: Daniluk, Cris [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, August 18, 1999 6:29 PM
> > > To: QMail (E-mail)
> > > Subject: queue not preprocessing
> > > 
> > > 
> > > I've noticed a couple times that qmail will stop 
> > > preprocessing messages and
> > > the queue will have say a thousand messages, but 900 of them 
> > > will not yet be
> > > preprocessed. Giving an ALRM to qmail-send does not seem to make a
> > > difference. Is there anything that would trigger this? It's 
> > > certainly got
> > > enough resources of every kind at its disposal...
> > > 
> > > Cris Daniluk
> > > MicroStrategy
> > > 
> 




"Daniluk, Cris" <[EMAIL PROTECTED]> wrote:

>It is actually prw--w---... is this a prob?

Yup. Let me guess: you "fixed" it because you saw it was world
writable? :-)

See:

    http://Web.InfoAve.Net/~dsill/lwq.html#trigger

-Dave




Daniluk, Cris writes:
 > One vital thing I forgot to mention is that after 20-30 minutes or so
 > they'll all get processed in a matter of seconds. This is less than
 > desireable because of the fact that these messages are alerts and therefore
 > need to be delivered as fast as humanly possible (which is why we use qmail!
 > :)

cd /usr/local/src/qmail-1.03
make setup

Your trigger fifo has been toasted.  make setup will fix it.

-- 
-russ nelson <[EMAIL PROTECTED]>  http://russnelson.com
Crynwr sells support for free software  | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | can outdo them. Homeschool!




Nope. I haven't touched any perms on the queue (I know how picky qmail is).
That's the result of make setup check; maybe something went wrong somewhere.
I'll run Eric Husses' queue-fix to catch any other errors that may be
present. Weird :)

> -----Original Message-----
> From: Dave Sill [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 18, 1999 6:46 PM
> To: [EMAIL PROTECTED]
> Subject: RE: queue not preprocessing
> 
> 
> "Daniluk, Cris" <[EMAIL PROTECTED]> wrote:
> 
> >It is actually prw--w---... is this a prob?
> 
> Yup. Let me guess: you "fixed" it because you saw it was world
> writable? :-)
> 
> See:
> 
>     http://Web.InfoAve.Net/~dsill/lwq.html#trigger
> 
> -Dave
> 




qmail-qstat showed 0 before I started.  I'm noticing that the problem is
worse, now that the queue is filling up.  Also, df -e reports 395k free
files.

> -----Original Message-----
> From: Russell Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 17, 1999 8:38 PM
> To: QMail List
> Subject: Re: question on big-todo patch
>
>
> Lyndon Griffin writes:
>  > I just installed the big-todo patch on one of my servers, and
> am running a
>  > mailing of around 350k names.  I am frequently getting the
> following error:
>  >
>  > find: cannot open queue/todo/117188: No such file or directory
>  > find: cannot open queue/todo/117514: No such file or directory
>  >
>  > any ideas?
>
> Did you clean out the queue after installing the patch?
>
> --
> -russ nelson <[EMAIL PROTECTED]>  http://russnelson.com
> Crynwr sells support for free software  | PGPok | Government
> schools are so
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any
> rank amateur
> Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | can outdo them.
> Homeschool!
>





Another thing I've noticed is that, although at the beginning I was running
at 100+ concurrent remotes, for the last several hours, I've been down
around 10.

> -----Original Message-----
> From: Russell Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 17, 1999 8:38 PM
> To: QMail List
> Subject: Re: question on big-todo patch
>
>
> Lyndon Griffin writes:
>  > I just installed the big-todo patch on one of my servers, and
> am running a
>  > mailing of around 350k names.  I am frequently getting the
> following error:
>  >
>  > find: cannot open queue/todo/117188: No such file or directory
>  > find: cannot open queue/todo/117514: No such file or directory
>  >
>  > any ideas?
>
> Did you clean out the queue after installing the patch?
>
> --
> -russ nelson <[EMAIL PROTECTED]>  http://russnelson.com
> Crynwr sells support for free software  | PGPok | Government
> schools are so
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any
> rank amateur
> Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | can outdo them.
> Homeschool!
>





On Wed, 18 Aug 1999 11:02:12 -0700, Lyndon Griffin wrote:

>>  > find: cannot open queue/todo/117188: No such file or directory
>>  > find: cannot open queue/todo/117514: No such file or directory

Something is very wrong. Are all programs patched? Patch applied
cleanly? There shouldn't be any todo/117188 with the big-todo patch.
One of the main things it does is subdivided the todo/ directory.


-Sincerely, Fred

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






Hi people,

I have one person on my server, which has LOTS of .qmail-files for his
domain. Now he has registered another domain and, renaming all those
.qmail-files so that they only apply to domain1 is not really an option. I
know I've seen a package somewhere, where I can specify a user and a
"homedirectory" for all that mail. It would be a lot easier to use
sudirectories to split those two domains, rather than .qmail-names. But
really I don't know how to do that, if some of you have some good ideas, or
where I can find that package, or something, I'd be very happy :-)


-Marthe
Ano-Tech Computers, www.atc.no

"It's the question that drives us.."





Marthe Nes�en Gangfl�t <[EMAIL PROTECTED]> wrote:
>
>I have one person on my server, which has LOTS of .qmail-files for his
>domain. Now he has registered another domain and, renaming all those
>.qmail-files so that they only apply to domain1 is not really an option. I
>know I've seen a package somewhere, where I can specify a user and a
>"homedirectory" for all that mail. It would be a lot easier to use
>sudirectories to split those two domains, rather than .qmail-names. But
>really I don't know how to do that, if some of you have some good ideas, or
>where I can find that package, or something, I'd be very happy :-)

You can do that with qmail-users. See:

    http://Web.InfoAve.Net/~dsill/lwq.html#qmail-users

Basically, you redirect the two domains to the user via
virtualdomains, e.g.:

    example.com:user-com
    example.net:user-net

Then create users/assign entries like:

    +user-com:user:UID:GID:/home/user/com:-::
    +user-net:user:UID:GID:/home/user/net:-::

And the .qmail files will go in ~user/com and ~user/net.

-Dave




How can I capture outgoing email to modify and append specific information
at the end of a message?

Thanks,
Jose






Jose de Leon writes:

> How can I capture outgoing email to modify and append specific information
> at the end of a message?

Add appropriate programming logic to either qmail-inject, or qmail-smtpd.



-- 
Sam





As I was searching for various patches at ftp sites, I got struck by
how many different names patches get --- and how many different
versions there are.  For example, there are 5 different versions of
the big-todo patch, and as a test, I'd ask the maintainers if they
know offhand under what name they are posted at their (or others') ftp
site. 

Often happens that the name does not suggest uniquely what package the
patch is supposed to patch (like `rbl.patch' could conceivably patch
at least three packages).

So I was thinking, perhaps a modest version control could be
implemented:  each patch file could have a name of the form

package-packageversion.patchname.patch

where the patch is supposed to patch package.

Like

qmail-1.03.big-todo.patch

Perhaps, the patchname could be followed by a version number (integer
is good enough), like

qmail-1.03.big-todo-21.patch

Similar conventions could be used for patches in tarballs, like

ezmlm-0.53.idx-0.322.tar.gz

(in this case, just kidding).

Since the patches are mostly posted to this list, it is probably not
difficult to keep track of the patch versions.  The best would be,
perhaps, if there was a maintainer of each patch, and people would
send their version to the maintainer.  (A higher version does not
necessarily mean improvement over a lower version, but a changelog would
keep track who submitted which version)

Finally, I found myself looking through all the patches to see if I
have to use -p0, -p1, etc.  I found two cases where I could have gone
either way: in the same patch file, I saw

qmail-1.03.orig/dns.c
qmail-1.03/dns.c
[...]
install.orig
install

There was one patch to call for -p4.

I know, none of the above problems are outrageous, but one can spend
considerable time on sorting out badly organized patches.  (Sorry, for
picking on the big-todo patc, but I still do not know, which one is
the latest, www.qmail.org's or Bruce G's.)

Sorry, for intruding

Mate




On Wed, Aug 18, 1999 at 11:39:05PM -0500, Mate Wierdl wrote:
> I know, none of the above problems are outrageous, but one can spend
> considerable time on sorting out badly organized patches.  (Sorry, for
> picking on the big-todo patc, but I still do not know, which one is
> the latest, www.qmail.org's or Bruce G's.)

It's certainly not mine -- I had no hand in creating this useful piece.
Whatever the qmail site points to should be authoritative for this one.

As far as versioning goes, it would probably be more useful to
date-stamp unversioned patches, to at least identify at what date the
patch originated.  This way, one could identify chronological order at
least.
-- 
Bruce Guenter, QCC Communications Corp.  EMail: [EMAIL PROTECTED]
Phone: (306)249-0220               WWW: http://www.qcc.sk.ca/~bguenter/




Hello!

My new mailsystem generates extra copies (2-3) of some of the
mails.
The users don't like to get 3 copies of the same mail at the same
time. :-)

I have no idea of where to start searching for the problem. Can
somebody send me some pointers?

Site description:

host1.domain.no: New Qmail server
host2.domain.no: New Qmail server
host3.domain.no: Sendmail server (will be replaced when
            everything is okay.)

host3 is connected to host1 & host2 with an ISDN-router.

So far the problem shows up when somebody on host2 send mails
til people at host3. The mail from host2 goes directly to host3.




Vennlig hilsen
Jon Lur�s




One of our former user was playing in many Internet-casinos. All these
casinos
send plenty of e-mails on the guy address up to now. This is bounced
back and they bounce it too. I would rather let the first message to us
die in /dev/null.
Need advice how to do it. Should I make a .qmail-user file?
How to deal with such problems If I have more of such former users?
Thanks
Andrzej





aw wrote:

> One of our former user was playing in many Internet-casinos. All these
> casinos
> send plenty of e-mails on the guy address up to now. This is bounced
> back and they bounce it too. I would rather let the first message to us
> die in /dev/null.

You could use the antispam patch from ftp://ftp.fmp.com/pub/linux/qmail/
and put the users address in control/badrcptto.

Claude

-- 
[EMAIL PROTECTED]
finger [EMAIL PROTECTED] for PGP-Public-Key


Reply via email to