Re: best patches to be apply for QMAIL

[Alan Clegg]

Unless the network is lying to me again, Henning Brauer said: 
> On Thu, Jun 07, 2001 at 06:24:16PM +0530, hari_bhr wrote:
> > i would like to know , what are the patches to be patch with this.
> > for more secure and with out any holes
> > could some one guide me what are the patches to be apply
> 
> Not a single one.

Speaking of qmail, that is.  Be *SURE* that you apply all patches to
the redhat O/S, as they seem to have much more difficulty getting it
right than qmail did.  ;-)

AlanC

Re: best patches to be apply for QMAIL

[Dave Sill]

"hari_bhr" <[EMAIL PROTECTED]> wrote:

>i would like to know , what are the patches to be patch with this.
>for more secure and with out any holes
>could some one guide me what are the patches to be apply

Any patches you apply are more likely to decrease security than
improve it. (No offense intended to patch authors, but DJB's record
speaks for itself.)

-Dave

Re: best patches to be apply for QMAIL

[Henning Brauer]

On Thu, Jun 07, 2001 at 06:24:16PM +0530, hari_bhr wrote:
> i would like to know , what are the patches to be patch with this.
> for more secure and with out any holes
> could some one guide me what are the patches to be apply

Not a single one.

-- 
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany   *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

RE: best patches to be apply for QMAIL

[Willy De la Court]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

If you are installing on RH 6.2 just install the RPM made by Bruce,
I'v Added some patches to daemontools etc you can find the src rpm's here with a 
little howto
http://www.quint.be/projects/

Willy De la Court
Quint NS NV

On Thursday, June 07, 2001 14:54, hari_bhr [SMTP:[EMAIL PROTECTED]] wrote:
> 
> hi
> 
> i have installed qmail 1.03 on redhat 6.2
> 
> i would like to know , what are the patches to be patch with this.
> for more secure and with out any holes
> could some one guide me what are the patches to be apply
> 
> thanks advance
> 
> 
> 
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOx8xzf4IaGw3x6aJEQJnWQCguGgAeeKcpBshm40iTwJdKQxvrPgAoNoZ
zFWD1PMaOGS/dAd82ToK5y4C
=FIVY
-END PGP SIGNATURE-

Re: best patches to be apply for QMAIL

[arjen-qmail]

there is no need to patch qmail 1.03 to make it more secure,
cos it already is very secure. Nobody found any hole up 'till 
now.

check http://www.qmail.org to see if you would patch it for
extra features.


Grtz, 

Arjen.


On Thu, 7 Jun 2001, hari_bhr wrote:

> hi
> 
> i have installed qmail 1.03 on redhat 6.2
> 
> i would like to know , what are the patches to be patch with this.
> for more secure and with out any holes
> could some one guide me what are the patches to be apply
> 
> thanks advance
> 
> 
> 
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 

best patches to be apply for QMAIL

[hari_bhr]

hi

i have installed qmail 1.03 on redhat 6.2

i would like to know , what are the patches to be patch with this.
for more secure and with out any holes
could some one guide me what are the patches to be apply

thanks advance



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: SPAM Patches recomendations.

[Jurjen Oskam]

On Thu, May 03, 2001 at 10:30:52AM -0500, q question wrote:
> 
> I know the qmail documentation says that the default for qmail is not to 
> relay. I need to see proof, not just be told to assume that the 
> documentation is correct. As I said above, I'll need time to reflect on 
> this.

You only need as much time as it takes to check the qmail log.

Does it send mail ANYWHERE (except bounces to the envelope sender) in response
to the "tests"? No? Then you're NOT an open relay and the "test" you used
doesn't Get It(tm).

> I do appreciate your reply and I realize full well that I may end up 
> deciding to ignore the Prodygy relay test failures someday myself.

That "someday" will be the day you check your logs.

-- 
  Jurjen Oskam * http://www.stupendous.org/ for PGP key * Q265230
  pro-life bombing bush hacker attack USA president 2600 decss assassinate
nuclear strike terrorism gun control eta military disrupt economy encryption
1:03pm  up 12 days, 16:49,  2 users,  load average: 0.07, 0.04, 0.01

Re: SPAM Patches recomendations.

[Charles Cazabon]

Alan Clegg <[EMAIL PROTECTED]> wrote:
> 
> > The particular assumption that Charles didn't explain is that
> > user%host2&host1 or host2|user@host1 will be relayed by host1
> > to user@host2.
 
> If anyone cares, this used to be completely legal and actually, a very 
> useful way of doing things.  There were a number of UUCP sites that were
> much quicker to address via:
> 
>   [EMAIL PROTECTED]
> 
> than giving the full ! path to the actual uucp site.  This was not "broken",
> it was "operational".

The brokenness comes from a third party looking at the local-part of that
address, and deducing that it implies relaying.  The most recent SMTP RFC
(2821) forbids this in section 2.3.10:

  The standard mailbox naming convention is defined to be "local-
  part@domain": contemporary usage permits a much broader set of applications
  than simple "user names".  Consequently, and due to a long history of
  problems when intermediate hosts have attempted to optimize transport by
  modifying them, the local-part MUST be interpreted and assigned semantics
  only by the host specified in the domain part of the address.

Prodygy (or whoever it was) was assuming that since a qmail server responded
with a 2xx code to

  RCPT TO: <[EMAIL PROTECTED]@baz.net>

that it would relay the mail.  That assumption is incorrect, and has always
been.  The fact that some sites will interpret the local-part of that address
and relay it does not mean that all sites which do not respond with a 4xx or
5xx code to that command should be identified as relays.

> I guess those days are gone, however.

So are the days of the 5-cent Coke and the sub-$1000 new car.  Doesn't mean
I'm wistful about them.

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---

Re: SPAM Patches recomendations.

[q question]

You don't need to look for any bugs to eat!

I haven't installed qmail yet, I'm still in the planning stages. I wanted to 
know how to test for relays and I appreciate your points.

Thanks! :)


>From: Greg White <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: SPAM Patches recomendations.
>Date: Thu, 3 May 2001 10:41:33 -0700
>
>On Thu, May 03, 2001 at 10:30:52AM -0500, q question wrote:
>SNIP
> > > > 2) How is it so clear that the machine didn't relay mail?
> > >
> > >-these types of questions come up every week on this mailing list
> > >-qmail has _never_ relayed mail unless the administrator specifically
> > >configures it to do so.
> >
> >
> > I know the qmail documentation says that the default for qmail is not to
> > relay. I need to see proof, not just be told to assume that the
> > documentation is correct. As I said above, I'll need time to reflect on
> > this. I appreciate that someone else suggested asking ORBS to do a relay
> > test. However, that doesn't necessarily reassure me that the Prodygy
> > Solutions relay test results should be ignored. I don't know anything
> > specific about the Prodygy relay test "failures" but I don't just ignore
> > something because someone else said to.
>
>'Proof'? If the relay test in question was acceptable, the OP would already
>have proof. A proper relay test involves the _actual receipt of relayed
>mail_. Try your own relay test, if you have addresses at multiple domains
>available, along the exact same lines as the 'tests' performed by
>prodigysolutions[1]. If you don't have another address available, use a
>friend's email account. If you manage to relay third-party mail through a
>qmail server with rcpthosts populated only with domains that you should
>actually deliver for (present in locals or virtualdomains[2]), and a
>properly set RELAYCLIENT environment variable, I will eat a bug on camera, 
>and
>give you links to watch it on the web. :)
>
>[1] I didn't recall seeing recent results for the
>'user@destination@relay' test, so I did them myself. Delivery attempt is
>to local user 'user@destination', which is unlikely to exist and in any
>case is not a relay. The '%' and '!' garbage comes up at least once a
>month, and is known _not_ to be a problem. Check that for yourself as
>well, if you like.
>
>[2] Or, of course, a domain that you're an MX for, but not the
>best-preference MX.
>
> >
> > I do appreciate your reply and I realize full well that I may end up
> > deciding to ignore the Prodygy relay test failures someday myself.
>
>Avoid the rush! Start ignoring them today! 'Tests' which assume that
>they know better than the MTA they are testing how it will deliver mail
>are inherently broken. 'Tests' which do not actually attempt to deliver
>mail anywhere, and do not only count the _actual receipt of mail_ as a
>successful relay (failed test) are inherently broken. As far as I am
>concerned, any 'test' that does not actually attempt delivery should
>immediately be ignored.
>
>
>SNIP
>
>GW

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: SPAM Patches recomendations.

[q question]

>What should convince you to ignore those tests is that they are providing a
>diagnosis ("Relay attempt succeeded") which is patently false (it isn't a
>successful relay unless the mail makes it to the final destination, and 
>they
>aren't even actually sending the mail, just testing the RCPT TO: command).
>
>Charles

Relay test 7
MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com)
250 ok
RCPT TO:("nobody%prodigysolutions.com")
250 ok  (Failed Test)
RSET
250 flushed

Relay test 13
MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com)
250 ok
RCPT TO:(prodigysolutions.com!nobody)
250 ok  (Failed Test)
RSET
250 flushed

I see your point, the "(Failed Test)" occurs immediately after
"RCPT TO: ..."
"250 ok"

This is why your (and Chris's) explanations about the assumptions are very 
useful, that the mail could be successfully received either for a local 
delivery, or for a relay, or perhaps not delivered at all.


_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: SPAM Patches recomendations.

[q question]

I appreciate your pointing this out.


>From: "Chris Garrigues" <[EMAIL PROTECTED]>
>To: "q question" <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: SPAM Patches recomendations.
>Date: Thu, 03 May 2001 11:24:49 -0500
>
> > From:  "q question" <[EMAIL PROTECTED]>
> > Date:  Thu, 03 May 2001 10:30:52 -0500
> >
> > >From: Charles Cazabon <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: SPAM Patches recomendations.
> > >Date: Thu, 3 May 2001 09:06:00 -0600
> > >
> > >It's also making some broken assumptions about how certain conventions 
>in
> > >the
> > >local-part of an SMTP envelope recipient address translate into 
>implicit
> > >relaying requests -- these conventions are not part of the SMTP
> > >specification,
> > >and qmail doesn't use them.  The fact that sendmail (or Domino, or
> > >Exchange,
> > >or whatever) is broken enough to do so should not implicate properly
> > >implemented SMTP servers.
> >
> >
> > I appreciate your describing this in detail. I'm going to need some time 
>to
> > reflect on these assumptions.
>
>The particular assumption that Charles didn't explain is that 
>user%host2&host1
>or host2|user@host1 will be relayed by host1 to user@host2.
>
>Certainly software that does this is broken, but it's also perfectly legal 
>for
>first%last@host1 or first!last@host1 to be delivered to an account on that
>machine.  To assume that the only reason such an address would be accepted 
>is
>to relay it is totally bogus.
>
>Chris
>
>--
>Chris Garrigues http://www.DeepEddy.Com/~cwg/
>virCIO  http://www.virCIO.Com
>4314 Avenue C
>Austin, TX  78751-3709 +1 512 374 0500
>
>   My email address is an experiment in SPAM elimination.  For an
>   explanation of what we're doing, see http://www.DeepEddy.Com/tms.html
>
> Nobody ever got fired for buying Microsoft,
>   but they could get fired for relying on Microsoft.
>
>
><< attach3 >>

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: SPAM Patches recomendations.

[Alan Clegg]

Unless the network is lying to me again, Chris Garrigues said: 

> The particular assumption that Charles didn't explain is that
> user%host2&host1 or host2|user@host1 will be relayed by host1
> to user@host2.
> 
> Certainly software that does this is broken, 

If anyone cares, this used to be completely legal and actually, a very 
useful way of doing things.  There were a number of UUCP sites that were
much quicker to address via:

[EMAIL PROTECTED]

than giving the full ! path to the actual uucp site.  This was not "broken",
it was "operational".  I guess those days are gone, however.

Just for fun, does anyone remember the issues surrounding:

[EMAIL PROTECTED]

Other fun thing that nolonger works:  finger user@somehost@otherhost 

AlanC
-- 
Alan Clegg  I do UNIX and Networks
  [EMAIL PROTECTED]I don't have any certification
  I have experience

Re: SPAM Patches recomendations.

[Greg White]

On Thu, May 03, 2001 at 10:30:52AM -0500, q question wrote:
SNIP
> > > 2) How is it so clear that the machine didn't relay mail?
> >
> >-these types of questions come up every week on this mailing list
> >-qmail has _never_ relayed mail unless the administrator specifically
> >configures it to do so.
> 
> 
> I know the qmail documentation says that the default for qmail is not to 
> relay. I need to see proof, not just be told to assume that the 
> documentation is correct. As I said above, I'll need time to reflect on 
> this. I appreciate that someone else suggested asking ORBS to do a relay 
> test. However, that doesn't necessarily reassure me that the Prodygy 
> Solutions relay test results should be ignored. I don't know anything 
> specific about the Prodygy relay test "failures" but I don't just ignore 
> something because someone else said to.

'Proof'? If the relay test in question was acceptable, the OP would already
have proof. A proper relay test involves the _actual receipt of relayed
mail_. Try your own relay test, if you have addresses at multiple domains
available, along the exact same lines as the 'tests' performed by
prodigysolutions[1]. If you don't have another address available, use a
friend's email account. If you manage to relay third-party mail through a
qmail server with rcpthosts populated only with domains that you should
actually deliver for (present in locals or virtualdomains[2]), and a
properly set RELAYCLIENT environment variable, I will eat a bug on camera, and
give you links to watch it on the web. :)

[1] I didn't recall seeing recent results for the
'user@destination@relay' test, so I did them myself. Delivery attempt is
to local user 'user@destination', which is unlikely to exist and in any
case is not a relay. The '%' and '!' garbage comes up at least once a
month, and is known _not_ to be a problem. Check that for yourself as
well, if you like. 

[2] Or, of course, a domain that you're an MX for, but not the
best-preference MX. 

> 
> I do appreciate your reply and I realize full well that I may end up 
> deciding to ignore the Prodygy relay test failures someday myself.

Avoid the rush! Start ignoring them today! 'Tests' which assume that
they know better than the MTA they are testing how it will deliver mail
are inherently broken. 'Tests' which do not actually attempt to deliver
mail anywhere, and do not only count the _actual receipt of mail_ as a
successful relay (failed test) are inherently broken. As far as I am
concerned, any 'test' that does not actually attempt delivery should
immediately be ignored. 


SNIP

GW

Re: SPAM Patches recomendations.

[Charles Cazabon]

q question <[EMAIL PROTECTED]> wrote:
> 
> I know the qmail documentation says that the default for qmail is not to
> relay. I need to see proof, not just be told to assume that the
> documentation is correct.

The proper "proof" is to try to relay yourself, and see if the message makes
it to its intended destination.  With qmail, you'll find that it doesn't.
Note that this isn't a proof in the mathematical sense.  For that, you'll need
to do a line-by-line analysis of the qmail source code.

> I appreciate that someone else suggested asking ORBS to do a relay test.
> However, that doesn't necessarily reassure me that the Prodygy Solutions
> relay test results should be ignored.

What should convince you to ignore those tests is that they are providing a
diagnosis ("Relay attempt succeeded") which is patently false (it isn't a
successful relay unless the mail makes it to the final destination, and they
aren't even actually sending the mail, just testing the RCPT TO: command).

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---

Re: SPAM Patches recomendations.

[Chris Garrigues]

> From:  "q question" <[EMAIL PROTECTED]>
> Date:  Thu, 03 May 2001 10:30:52 -0500
>
> >From: Charles Cazabon <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: SPAM Patches recomendations.
> >Date: Thu, 3 May 2001 09:06:00 -0600
> >
> >It's also making some broken assumptions about how certain conventions in 
> >the
> >local-part of an SMTP envelope recipient address translate into implicit
> >relaying requests -- these conventions are not part of the SMTP 
> >specification,
> >and qmail doesn't use them.  The fact that sendmail (or Domino, or 
> >Exchange,
> >or whatever) is broken enough to do so should not implicate properly
> >implemented SMTP servers.
> 
> 
> I appreciate your describing this in detail. I'm going to need some time to
> reflect on these assumptions.

The particular assumption that Charles didn't explain is that user%host2&host1
or host2|user@host1 will be relayed by host1 to user@host2.

Certainly software that does this is broken, but it's also perfectly legal for 
first%last@host1 or first!last@host1 to be delivered to an account on that 
machine.  To assume that the only reason such an address would be accepted is 
to relay it is totally bogus.

Chris

-- 
Chris Garrigues http://www.DeepEddy.Com/~cwg/
virCIO  http://www.virCIO.Com
4314 Avenue C   
Austin, TX  78751-3709  +1 512 374 0500

  My email address is an experiment in SPAM elimination.  For an
  explanation of what we're doing, see http://www.DeepEddy.Com/tms.html 

Nobody ever got fired for buying Microsoft,
  but they could get fired for relying on Microsoft.



 PGP signature

Re: SPAM Patches recomendations.

[q question]

>From: Charles Cazabon <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: SPAM Patches recomendations.
>Date: Thu, 3 May 2001 09:06:00 -0600
>
>q question <[EMAIL PROTECTED]> wrote:
> >
> > 1) What are the erroneous assumptions of the Prodygy relay test utility?
>
>It assumes that because the RCPT TO: <...> command succeeded, the mail will 
>be
>delivered.  This is not required by RFC821/2821, and is not true of qmail 
>or
>any other MTA which does not have knowledge of the possible final delivery
>targets during the initial SMTP conversation.
>
>It's also making some broken assumptions about how certain conventions in 
>the
>local-part of an SMTP envelope recipient address translate into implicit
>relaying requests -- these conventions are not part of the SMTP 
>specification,
>and qmail doesn't use them.  The fact that sendmail (or Domino, or 
>Exchange,
>or whatever) is broken enough to do so should not implicate properly
>implemented SMTP servers.


I appreciate your describing this in detail. I'm going to need some time to 
reflect on these assumptions.


> > 2) How is it so clear that the machine didn't relay mail?
>
>-these types of questions come up every week on this mailing list
>-qmail has _never_ relayed mail unless the administrator specifically
>configures it to do so.


I know the qmail documentation says that the default for qmail is not to 
relay. I need to see proof, not just be told to assume that the 
documentation is correct. As I said above, I'll need time to reflect on 
this. I appreciate that someone else suggested asking ORBS to do a relay 
test. However, that doesn't necessarily reassure me that the Prodygy 
Solutions relay test results should be ignored. I don't know anything 
specific about the Prodygy relay test "failures" but I don't just ignore 
something because someone else said to.

I do appreciate your reply and I realize full well that I may end up 
deciding to ignore the Prodygy relay test failures someday myself.


_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: SPAM Patches recomendations.

[Charles Cazabon]

q question <[EMAIL PROTECTED]> wrote:
> 
> 1) What are the erroneous assumptions of the Prodygy relay test utility?

It assumes that because the RCPT TO: <...> command succeeded, the mail will be
delivered.  This is not required by RFC821/2821, and is not true of qmail or
any other MTA which does not have knowledge of the possible final delivery
targets during the initial SMTP conversation.

It's also making some broken assumptions about how certain conventions in the
local-part of an SMTP envelope recipient address translate into implicit
relaying requests -- these conventions are not part of the SMTP specification,
and qmail doesn't use them.  The fact that sendmail (or Domino, or Exchange,
or whatever) is broken enough to do so should not implicate properly
implemented SMTP servers.

> 2) How is it so clear that the machine didn't relay mail?

-these types of questions come up every week on this mailing list
-qmail has _never_ relayed mail unless the administrator specifically
configures it to do so.

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---

Re: SPAM Patches recomendations.

[q question]

Charles,

1) What are the erroneous assumptions of the Prodygy relay test utility?
2) How is it so clear that the machine didn't relay mail?

>From: Charles Cazabon <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: SPAM Patches recomendations.
>Date: Tue, 1 May 2001 09:52:51 -0600
>
>Eduardo Augusto Alvarenga <[EMAIL PROTECTED]> wrote:
> >
> > I've tested my qmail smtp server for spam using the Prodygy Solutions
> > relay test utility:
>[...]
> > And got 2(two) holes on my server:
>
>No, you don't.  Your machine didn't relay mail, and the tests (hah!) didn't
>even actually do any testing; they inferred a result from erroneous
>assumptions.
>
>Ignore the "tests" you did; they're worthless, and tell you nothing about
>whether your server is an open relay or not.  Provided you have
>/var/qmail/control/rcpthosts, and it contains only your domains, and you're
>not setting the RELAYCLIENT environment variable for random IP addresses 
>which
>connect to your SMTP port, then you are NOT an open relay.
>
>Charles
>--
>---
>Charles Cazabon<[EMAIL PROTECTED]>
>GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
>Any opinions expressed are just that -- my opinions.
>---

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: SPAM Patches recomendations.

[Keary Suska]

You are better off asking ORBS to do a relay test, which is more reliable.
http://www.orbs.org/

-K

"Do not meddle in the affairs of dragons, because you are crunchy and taste
good with ketchup."


> From: Eduardo Augusto Alvarenga <[EMAIL PROTECTED]>
> Date: Tue, 01 May 2001 12:15:19 -0300
> To: [EMAIL PROTECTED]
> Subject: SPAM Patches recomendations.
> 
> Greetz,
> 
> I've tested my qmail smtp server for spam using the Prodygy Solutions
> relay test utility:
> 
> http://www.prodigysolutions.com/services/relay_test.php
> 
> And got 2(two) holes on my server:
> 
> * I'll omit the domain for security reasons of course.
> 
> Relay test 7
> MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com)
> 250 ok 
> RCPT TO:("nobody%prodigysolutions.com")
> 250 ok  (Failed Test)
> RSET
> 250 flushed 
> 
> Relay test 13
> MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com)
> 250 ok 
> RCPT TO:(prodigysolutions.com!nobody)
> 250 ok  (Failed Test)
> RSET
> 250 flushed 
> 
> 
> Anyone has any tip to fix these problems ? (patches/etc) ?
> Another question: Emails on using % and ! as the domain separator should
> work ?
> 
> 
> Best Regards,
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Eduardo Augusto Alvarenga - Analista de Suporte - #179653
> Blumenau - Santa Catarina. Tel. (47) 9102-3303
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> /"\
> \ /  Campanha da Fita ASCII - Contra Mail HTML
> X   ASCII Ribbon Campaign - Against HTML Mail
> / \
> 

Re: SPAM Patches recomendations.

[Charles Cazabon]

Eduardo Augusto Alvarenga <[EMAIL PROTECTED]> wrote:
> 
> I've tested my qmail smtp server for spam using the Prodygy Solutions
> relay test utility:
[...] 
> And got 2(two) holes on my server:

No, you don't.  Your machine didn't relay mail, and the tests (hah!) didn't
even actually do any testing; they inferred a result from erroneous
assumptions.

Ignore the "tests" you did; they're worthless, and tell you nothing about
whether your server is an open relay or not.  Provided you have
/var/qmail/control/rcpthosts, and it contains only your domains, and you're
not setting the RELAYCLIENT environment variable for random IP addresses which
connect to your SMTP port, then you are NOT an open relay.

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---

SPAM Patches recomendations.

[Eduardo Augusto Alvarenga]

Greetz,

I've tested my qmail smtp server for spam using the Prodygy Solutions
relay test utility:

http://www.prodigysolutions.com/services/relay_test.php

And got 2(two) holes on my server:

* I'll omit the domain for security reasons of course.

 Relay test 7
 MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com)
 250 ok 
 RCPT TO:("nobody%prodigysolutions.com")
 250 ok  (Failed Test)
 RSET
 250 flushed 
  
 Relay test 13
 MAIL FROM:([EMAIL PROTECTED]@mail.mydomain.com)
 250 ok 
 RCPT TO:(prodigysolutions.com!nobody)
 250 ok  (Failed Test)
 RSET
 250 flushed 


Anyone has any tip to fix these problems ? (patches/etc) ?
Another question: Emails on using % and ! as the domain separator should
work ?


Best Regards,

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Eduardo Augusto Alvarenga - Analista de Suporte - #179653
Blumenau - Santa Catarina. Tel. (47) 9102-3303
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 /"\
 \ /  Campanha da Fita ASCII - Contra Mail HTML
  X   ASCII Ribbon Campaign - Against HTML Mail
 / \

Re: Best qmail patches for hosting email for many domains

[Charles Cazabon]

Qmail <[EMAIL PROTECTED]> wrote:
> 
> Can anyone suggest some patches that will give me:
> 
> Virtual POP/SMTP (IMAP would be nice)

Not a patch, but vmailmgr does this well (the benefits of modularity, you
see).  See http://www.vmailmgr.org/ for details.

> A web interface to add/delete/change passwords/setup forwards (auto
> responders would be nice)

I believe oMail has this.  You can find it at SourceForge or Freshmeat.

> Only 1 IP per server

vmailmgr can handle multiple virtual domains per IP address.

> quota per domain

vmailmgr lets you use normal filesystem quotas for this.  It also supports
per-virtual-user quotas.

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---

Re: Best qmail patches for hosting email for many domains

[Rick Updegrove]

> Can anyone suggest some patches that will give me:
> Virtual POP/SMTP (IMAP would be nice)

vpopmail 

> A web interface to add/delete/change passwords/setup forwards (auto
> responders would be nice)

qmailadmin

> Only 1 IP per server
> Niceties:
> mySQL backend
> simple way to count and bill per account/domain.
> quota per domain

all at  http://inter7.com/freesoftware/index.html

Rick Up

Best qmail patches for hosting email for many domains

[Qmail]

I'm looking to upgrade our existing hacked qmail system.

We running v1.02 with a custom web interface to a virtual mail manager.

It works great. But the code requires an IP per domain to do POP.

I know there are other options at this point, and I'd like not to be the
only one maintaining the code, if at all.

Can anyone suggest some patches that will give me:

Virtual POP/SMTP (IMAP would be nice)
A web interface to add/delete/change passwords/setup forwards (auto
responders would be nice)
Only 1 IP per server

Niceties:
mySQL backend
simple way to count and bill per account/domain.
quota per domain

Lance

RE: Recommended patches for high-volume ezmlm server

[Don Rose]

So having multiple QMQP machines as opposed to a single machine wouldn't
deliver the mail faster?  We've already got the LocalDirector in place
doing other things and we wanted to utilize it for this if we could.

For this usage, its not a matter of redundant failover, but more a
matter of load balancing, so that 3 machines can deliver millions of
emails faster than a single one could.

Am I wrong in my thinking here?

-Original Message-
From: Peter van Dijk [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 10, 2001 3:53 AM
To: '[EMAIL PROTECTED]'
Subject: Re: Recommended patches for high-volume ezmlm server


On Fri, Mar 09, 2001 at 08:40:53AM -0800, Don Rose wrote:
> Actually the lists are only announcement-type lists so users won't be
> posting, so the only messages that should be queued are like you said
> the bounce probes, and the messages the mods post to it.
> 
> I was thinking of setting up 2 or 3 QMQP servers on a LocalDirector to
> handle the actual sending of the messages, so the original machine
isn't
> too busy to recieve new mail.

Using a LocalDirector for QMQP is overkill. If one of your QMQP
servers is down, the 'clients' will use another one automatically.
This just means a slight delay, and nothing to worry about.

Greetz, Peter.

Re: Recommended patches for high-volume ezmlm server

[Peter van Dijk]

On Fri, Mar 09, 2001 at 08:40:53AM -0800, Don Rose wrote:
> Actually the lists are only announcement-type lists so users won't be
> posting, so the only messages that should be queued are like you said
> the bounce probes, and the messages the mods post to it.
> 
> I was thinking of setting up 2 or 3 QMQP servers on a LocalDirector to
> handle the actual sending of the messages, so the original machine isn't
> too busy to recieve new mail.

Using a LocalDirector for QMQP is overkill. If one of your QMQP
servers is down, the 'clients' will use another one automatically.
This just means a slight delay, and nothing to worry about.

Greetz, Peter.

Re: Recommended patches for high-volume ezmlm server

[Peter van Dijk]

On Fri, Mar 09, 2001 at 10:24:11AM -0600, Mate Wierdl wrote:
> On Thu, Mar 08, 2001 at 09:48:22PM +0100, Peter van Dijk wrote:
> > On Thu, Mar 08, 2001 at 12:16:52PM -0800, Don Rose wrote:
> > > I am building a server to house several very high volume mailing lists
> > > (2-4M users each) and wanted to know which patches were recommended for
> > > use with ezmlm and ezmlm-idx, as well as qmail itself.
> > > 
> > > I have read about the big-concurrency patch and that seems relevant, but
> > > I'm not sure about the others.
> > 
> > No others are.
> 
> I am theorizing: having millions of users means lots of bad addresses.
> So now, when ezmlm-warn sends out its gripes, it may mean a few
> hundred thousand separate messages in the queue.  Is that a load in
> the queue not to worry about?  

Those don't get send out all at the same time.

And your theory is broken - ezmlm subscriber lists are almost by
definition high-quality.

Greetz, Peter.

RE: Recommended patches for high-volume ezmlm server

[Don Rose]

Actually the lists are only announcement-type lists so users won't be
posting, so the only messages that should be queued are like you said
the bounce probes, and the messages the mods post to it.

I was thinking of setting up 2 or 3 QMQP servers on a LocalDirector to
handle the actual sending of the messages, so the original machine isn't
too busy to recieve new mail.

-Original Message-
From: Mate Wierdl [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 09, 2001 8:24 AM
To: [EMAIL PROTECTED]
Subject: Re: Recommended patches for high-volume ezmlm server


On Thu, Mar 08, 2001 at 09:48:22PM +0100, Peter van Dijk wrote:
> On Thu, Mar 08, 2001 at 12:16:52PM -0800, Don Rose wrote:
> > I am building a server to house several very high volume mailing
lists
> > (2-4M users each) and wanted to know which patches were recommended
for
> > use with ezmlm and ezmlm-idx, as well as qmail itself.
> > 
> > I have read about the big-concurrency patch and that seems relevant,
but
> > I'm not sure about the others.
> 
> No others are.

I am theorizing: having millions of users means lots of bad addresses.
So now, when ezmlm-warn sends out its gripes, it may mean a few
hundred thousand separate messages in the queue.  Is that a load in
the queue not to worry about?  

Mate

Re: Recommended patches for high-volume ezmlm server

[Mate Wierdl]

On Thu, Mar 08, 2001 at 09:48:22PM +0100, Peter van Dijk wrote:
> On Thu, Mar 08, 2001 at 12:16:52PM -0800, Don Rose wrote:
> > I am building a server to house several very high volume mailing lists
> > (2-4M users each) and wanted to know which patches were recommended for
> > use with ezmlm and ezmlm-idx, as well as qmail itself.
> > 
> > I have read about the big-concurrency patch and that seems relevant, but
> > I'm not sure about the others.
> 
> No others are.

I am theorizing: having millions of users means lots of bad addresses.
So now, when ezmlm-warn sends out its gripes, it may mean a few
hundred thousand separate messages in the queue.  Is that a load in
the queue not to worry about?  

Mate

Re: Recommended patches for high-volume ezmlm server

[Peter van Dijk]

On Thu, Mar 08, 2001 at 12:16:52PM -0800, Don Rose wrote:
> I am building a server to house several very high volume mailing lists
> (2-4M users each) and wanted to know which patches were recommended for
> use with ezmlm and ezmlm-idx, as well as qmail itself.
> 
> I have read about the big-concurrency patch and that seems relevant, but
> I'm not sure about the others.

No others are.

Greetz, Peter.

Recommended patches for high-volume ezmlm server

[Don Rose]

I am building a server to house several very high volume mailing lists
(2-4M users each) and wanted to know which patches were recommended for
use with ezmlm and ezmlm-idx, as well as qmail itself.

I have read about the big-concurrency patch and that seems relevant, but
I'm not sure about the others.

Can someone give me a heads up?  Thank you.

concurrency patches

[Sumith Ail]

HI
 
I have applied Russ Nelsons Big TO DO Patch and Big 
concurency patch
 
Is this enough for qmail to handle a large number 
of simultaneous deliveries or I need to specify it in qmail-control
 
Please explain me as I have just started with 
Qmail.
 
also i see that Dave Smith of Xoom.com has updated 
the Big-to-do patch... Is the updated one recommended or the original is good 
enough.
 
Regards
Sumith

Re: Patches

[Charles Cazabon]

Sumith Ail <[EMAIL PROTECTED]> wrote:
> You mean that the memphis RPM's without any patches are fine to be run on
> production servers.

Yes.  It wouldn't be a particularly useful piece of software otherwise.

This just re-illustrates Russell's point about people misinterpreting what
the "patches" section of qmail.org is all about.

How about "Third-party functional differentiation utilities"? :)

Charles
-- 
---
Charles Cazabon<[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
---

Re: Patches

[Sumith Ail]

Hi
You mean that the memphis RPM's without any patches are fine to be run on
production servers.

Regards
-Sumith
- Original Message -
From: Markus Stumpf <[EMAIL PROTECTED]>
To: Sumith Ail <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 23, 2001 4:58 PM
Subject: Re: Patches


> On Tue, Jan 23, 2001 at 02:45:39PM +0530, Sumith Ail wrote:
> > We are planning to install Qmail on a production server which will have
> > around 500+ virtual domains. I am aware that some patches need to be
> > applied to qmail before it can be used on a production server.
>
> This is wrong.
>
> > Can someone please let me know on what are the necessary patches to be
> > applied. I am using the latest memphis RPM's of Qmail, daemontools and
> > ucspi-tcp package. So I would like to know on which are the most
> > required patches to these RPM's
>
> You don't need any patches.
> If you like modifications of some sort see
> http://www.qmail.org/
> and pick what you like.
>
> \Maex
>
> --
> SpaceNet AG   |   http://www.Space.Net/   | Stress is when you
wake
> Research & Development| mailto:[EMAIL PROTECTED] | up screaming and
you
> Joseph-Dollinger-Bogen 14 |  Tel: +49 (89) 32356-0| realize you
haven't
> D-80807 Muenchen  |  Fax: +49 (89) 32356-299  | fallen asleep yet.
>

Re: Patches

[Markus Stumpf]

On Tue, Jan 23, 2001 at 02:45:39PM +0530, Sumith Ail wrote:
> We are planning to install Qmail on a production server which will have 
> around 500+ virtual domains. I am aware that some patches need to be
> applied to qmail before it can be used on a production server.

This is wrong.

> Can someone please let me know on what are the necessary patches to be 
> applied. I am using the latest memphis RPM's of Qmail, daemontools and 
> ucspi-tcp package. So I would like to know on which are the most 
> required patches to these RPM's

You don't need any patches.
If you like modifications of some sort see
http://www.qmail.org/
and pick what you like.

\Maex

-- 
SpaceNet AG   |   http://www.Space.Net/   | Stress is when you wake
Research & Development| mailto:[EMAIL PROTECTED] | up screaming and you
Joseph-Dollinger-Bogen 14 |  Tel: +49 (89) 32356-0| realize you haven't
D-80807 Muenchen  |  Fax: +49 (89) 32356-299  | fallen asleep yet.

Patches

[Sumith Ail]

Dear AllWe are planning to install Qmail on 
a production server which will have around 500+ virtual domains. I am aware 
that some patches need to beapplied to qmail before it can be used on a 
production server.Can someone please let me know on what are the 
necessary patches to be applied. I am using the latest memphis RPM's of 
Qmail, daemontools and ucspi-tcp package. So I would like to know on which 
are the most required patches to these RPM'sThanks in 
advance.RegardsSumith

Re: CNAME errors, qmail-1.03+patches-18

[Christopher K Davis]

Corey Crawford <[EMAIL PROTECTED]> writes:

> I'm running into the CNAMEs error that everyone else seems to have trouble 
> with at some point in time. I have Bruce's qmail-patch18 version of qmail 
> (which includes the big-dns patch) but I'm still having quiet a lot of 
> trouble. Here's an example:
[...]
> Notice that it works just fine after I do an nslookup for hotmail.com.
> Course, after awhile that seems to go away and I have to redo an 'nslookup 
> hotmail.com' to get emails to hotmail.com to work.

> Anyone have any ideas what might be causing this?

Sounds like a DNS caching problem.  Since you're running BIND 8, you
should have dig (better than nslookup).  So next time it happens try:

dig hotmail.com any +norec

That will show you what is in BIND's cache for hotmail.com (the +norec
will make it a non-recursive query).

My guess is that your cache is getting confused somehow and is failing
to look up hotmail.com.  Why?  Well, since hotmail in their infinite
wis-dumb has put 30 minute TTLs on their in-zone NS records, I suspect
that has something to do with it

You may want to consider moving to djbdns instead of BIND.  It probably
deals with this better.

-- 
Christopher Davis * <[EMAIL PROTECTED]> * http://www.ckdhr.com/ckd/>
Put location information in your DNS! http://www.ckdhr.com/dns-loc/>

CNAME errors, qmail-1.03+patches-18

[Corey Crawford]

Evening folks.

I'm running into the CNAMEs error that everyone else seems to have trouble 
with at some point in time. I have Bruce's qmail-patch18 version of qmail 
(which includes the big-dns patch) but I'm still having quiet a lot of 
trouble. Here's an example:

- LOG FOR NEW MESSAGE -

Jan 19 17:18:17 seventh qmail: 979949897.984215 new msg 1134325
Jan 19 17:18:17 seventh qmail: 979949897.984701 info msg 1134325: bytes 805 
from <[EMAIL PROTECTED]> qp 21196 uid 101
Jan 19 17:18:18 seventh qmail: 979949898.016691 starting delivery 7: msg
1134325 to local [EMAIL PROTECTED]
Jan 19 17:18:18 seventh qmail: 979949898.016964 status: local 1/10 remote
0/20
Jan 19 17:18:18 seventh qmail: 979949898.017095 starting delivery 8: msg
1134325 to remote [EMAIL PROTECTED]
Jan 19 17:18:18 seventh qmail: 979949898.017218 status: local 1/10 remote
1/20
Jan 19 17:18:18 seventh qmail: 979949898.065016 delivery 7: success: 
did_0+0+0/
Jan 19 17:18:18 seventh qmail: 979949898.070105 status: local 0/10 remote
1/20
Jan 19 17:18:38 seventh qmail: 979949918.075619 delivery 8: deferral:
CNAME_lookup_failed_temporarily._(#4.4.3)/
Jan 19 17:18:38 seventh qmail: 979949918.076077 status: local 0/10 remote
0/20

- RUN NSLOOKUP ON HOTMAIL -

% nslookup hotmail.com

- SEND SIGNAL 'ALRM' TO QMAIL-SEND TO RESEND EVERYTHING -

% kill -ALRM 12345

- LOG FOR RESENDING -

Jan 19 17:20:49 seventh qmail: 979950049.559996 starting delivery 9: msg
1134325 to remote [EMAIL PROTECTED]
Jan 19 17:20:49 seventh qmail: 979950049.560413 status: local 0/10 remote
1/20
Jan 19 17:20:50 seventh qmail: 979950050.259506 delivery 9: success:
216.32.243.136_accepted_message./Remote_host_said:_250_Requested_mail_action_okay,_completed/
Jan 19 17:20:50 seventh qmail: 979950050.264649 status: local 0/10 remote
0/20
Jan 19 17:20:50 seventh qmail: 979950050.265027 end msg 1134325

Notice that it works just fine after I do an nslookup for hotmail.com.
Course, after awhile that seems to go away and I have to redo an 'nslookup 
hotmail.com' to get emails to hotmail.com to work.

Anyone have any ideas what might be causing this?

Could it have something to do with unix-tcp? I think I have version .88-1.

Thanks! :)

Oh, this is on a RedHat 7.0 server, with BIND 8. Also, qmail won't do a
reverse lookup on the domains in the 'control/virtualhosts' file, and I
believe it's a related problem. Btw, I didn't have this problem on RedHat
6.0 with the same files (cept it was qmail-1.03+patches-17).

Appreciate any help!


\=/,_-===-_--_-==-_-===-_--_
|  @___oo  ( Corey  Crawford)
  /\  /\   / (___,,,}_-=[EMAIL PROTECTED]   )_
 ) /^\) ^\/ _)=__ TajanaMUD / seventh.net  )
 )   /^\/   _)  (_seventh.net 7070)
 )   _ /  / _)-===-___--___-=-___-===-
/\  )/\/ ||  | )_)
<  >  |(,,) )__)
||  /\)___)\
| \(  )___) )___
  \__(___;;; __;;;
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: necessary patches?

[Dave Sill]

Clemens Hermann <[EMAIL PROTECTED]> wrote:

>So my question is: Which patches should one not miss. 

I don't install any patches unless I know I need them. Only two of the
dozens of qmails I've installed have been patched:

  - my list server has the big-concurrency patch, and
  - a pop/imap/smtp server I installed for a customer required the
    AUTH and STARTLS patches.

>POP3/SMTP (no imap, no qmtp)

No patches required.

>smtp-after-pop and smtp-auth

Requires AUTH patch (I recommend Krzysztof Dabrowski's patch) and
open-smtp add-on.

>tarpiting RBL

Probably requires a patch, but I've never done this.

>vmailmgr / omail-admin
>omail
>(if possible) POP3/smtp ssl optional
>EZMLM

These are all add-ons unless I'm mistaken.

-Dave

necessary patches?

[Clemens Hermann]

Hi,

now I have been using qmail for several months and I am quite satisfied. I
change my server HW and for this and some other reasons I reinstall my
System from scratch (FreeBSD 4.2).
I have been digging around in the qmail.org page to find out which
patches are needed for me. I was really overwhelmed and I do not really
know much more than before ;-).
So my question is: Which patches should one not miss. 
I will make things as described in LWQ and I would appreciate it if I
could patch things during installation so that I do not have to apply
patches when the system is in use but I do not know which combination I
should use and (even more imortant): which combination works?
I know, depends on my needs ;-). Hmmm, I plan the following things:

POP3/SMTP (no imap, no qmtp)
smtp-after-pop and smtp-auth
tarpiting RBL
vmailmgr / omail-admin
omail
(if possible) POP3/smtp ssl optional
EZMLM

that's it ;-)
The load will be low.

Are there any hints which patches should be applied in general not
to be sorry some weeks later.

Thanks in andvance

Clemens

Re: several patches

[Dave Sill]

"Clemens Hermann" <[EMAIL PROTECTED]> wrote:

>At the moment I am looking at quite a hand full of qmail patches I would
>like to use.  May there occur problems combinig different patches which run
>great if they are alone?

Yes.

>If there are problems in interaction between different patches will I most
>likely know this by a compile-error or might there be some problems which
>occur at runtime or (even worse) create security problems?

Any of these outcomes are possible, but if the patches apply cleanly,
chances are good that they won't interact badly.

>Can I avoid these problems in patching the qmail sources manually?

Possibly. That depends on how good of a programmer you are. :-)

Personally, I try to avoid all patches. Do you really *need* this
large list of patches, or do you just think they'd be nice to have?

-Dave

several patches

[Clemens Hermann]

Hello again,

first of all, thanks once again to all of you who provided me with a large
variety of very helpful information yestarday.
At the moment I am looking at quite a hand full of qmail patches I would
like to use.  May there occur problems combinig different patches which run
great if they are alone?
If there are problems in interaction between different patches will I most
likely know this by a compile-error or might there be some problems which
occur at runtime or (even worse) create security problems?
Can I avoid these problems in patching the qmail sources manually?

thanks in advance

Clemens

bug in flame-patches-1.03-1.6.2.diff, patch provided.

[Brian Behlendorf]

Here's a copy of the message I sent to [EMAIL PROTECTED] regarding a bug in
the flame.org patch; since it's fairly serious (rejecting valid messages
that follow identified spam in a single SMTP conversation) I thought I'd
post it here in case others were using it.

Brian


-- Forwarded message --
Date: Thu, 14 Sep 2000 11:08:15 -0700 (PDT)
From: Brian Behlendorf <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: bug in flame-patches-1.03-1.6.2.diff, patch provided.


Uh, there appears to be a serious bug in your flame patches - if a remote
MTA transfers multiple messages over the same SMTP conversation (i.e.,
sends a message, and instead of closing the SMTP conversation, starts a
new message) then if one message in that stream exceeded the badheader
threshold and is rejected, then all subsequent ones in that stream will
also be rejected.

I noticed this when the apache.org mail box was down for a little bit and
when it came back up, the backup MX streamed a bunch of messages to it,
and a whole series of them failed.  Here's a good illustration of the
problem:

Sep 13 11:41:10 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:11 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:19 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:21 locus qmail-smtpd[43346]: REJECT JUNK_THRESHOLD <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> [63.161.32.6, unknown] (HELO zuul.interlinksystems.com) 0/1000/R
Sep 13 11:41:41 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:41 locus qmail-smtpd[43346]: REJECT JUNK_THRESHOLD 
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> [63.161.32.6, unknown] (HELO 
zuul.interlinksystems.com) 0/1000/R
Sep 13 11:41:51 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:52 locus qmail-smtpd[43346]: REJECT JUNK_THRESHOLD <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> [63.161.32.6, unknown] (HELO zuul.interlinksystems.com) 0/1000/R
Sep 13 11:41:54 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:54 locus qmail-smtpd[43346]: REJECT JUNK_THRESHOLD <> 
<[EMAIL PROTECTED]> [63.161.32.6, unknown] (HELO 
zuul.interlinksystems.com) 0/1000/R
Sep 13 11:41:55 locus qmail-smtpd[43346]: Received: from unknown (HELO 
zuul.interlinksystems.com)
Sep 13 11:41:55 locus qmail-smtpd[43346]: REJECT JUNK_THRESHOLD <> 
<[EMAIL PROTECTED]> [63.161.32.6, unknown] (HELO 
zuul.interlinksystems.com) 0/1000/R

As you can see, the [EMAIL PROTECTED] was a badheaders spam, but the
rest of the ones after that also failed.  Baaad.  

I think the following patch appears to fix it:

locus# diff -C3 qmail-smtpd.c.old qmail-smtpd.c
*** qmail-smtpd.c.old   Thu Sep 14 11:07:06 2000
--- qmail-smtpd.c   Thu Sep 14 11:04:31 2000
***
*** 843,848 
--- 843,849 
if (remotehost)
  log_helo();
headerthresh = 0;
+   headeralways = ALWAYS_RATE;
blast(&hops);
hops = (hops >= MAXHOPS);
if (hops) qmail_fail(&qqt);

I tested it and it appears to not block subsequent requests if the first
one fails.  I could be misunderstanding your code though.

Thoughts?  

Brian

RE: RPM with patches - lost the URL where it is

[Charles Warwick]

http://em.ca/~bruceg/qmail+patches/

-Original Message-
From: Pete Lancashire [mailto:[EMAIL PROTECTED]]
Sent: Friday, 1 September 2000 12:42 PM
To: [EMAIL PROTECTED]
Subject: RPM with patches - lost the URL where it is 


I just lost a URL where someone has done a nice
job of adding many patches to Qmail and putting
it all into a SRPM.

I hope someone can point me to the site/person.

TIA !!!

-pete

RPM with patches - lost the URL where it is

[Pete Lancashire]

I just lost a URL where someone has done a nice
job of adding many patches to Qmail and putting
it all into a SRPM.

I hope someone can point me to the site/person.

TIA !!!

-pete

Re: patching qmail with multiple patches

[Michael T. Babcock]

Also double-check with the appropriate patch author (especially if its a
larger patch, like LDAP) to see which configurations he/she has tested it
with.

- Original Message -
From: "Dave Sill" <[EMAIL PROTECTED]>

> I would:
>
> 1) Select only patches that I have a proven or mandated need for. For
>example, I haven't seen DNS problems, so I'd skip that one.
> 2) For the remaining patches, I'd construct a matrix showing which
>patches modified which files.
> 3) If any files are modified by more than one patch, I'd read the
>patch files to see where the modifications are being made.
> 4) If more than one patch modifies the same original qmail code, I'd
>strongly consider dropping one of the patches or finding a
>competent programmer to merge them. This could be tricky and/or a
>lot of work.
> 5) Use "patch" to install non-conflicting patches.
> 6) Manually install conflicting and failed patches.
> 7) Build qmail per INSTALL and patch-specific instructions.
> 8) Test, test, test.
> 9) Test some more, but still expect the unexpected.

Re: patching qmail with multiple patches

[Dave Sill]

[EMAIL PROTECTED] wrote:

>  i am trying to apply following patches on qmail-1.03 , but not able to
>apply all those 
>
>  1> qmail-bounce.patch
>  2> qmail-ldap-2601.patch
>  3> patching dns.c  with appropriate patch 
>  4> qmail-big-concurrency.patch 
>  5> qmail-big-todo. patch  

I would:

1) Select only patches that I have a proven or mandated need for. For
   example, I haven't seen DNS problems, so I'd skip that one.
2) For the remaining patches, I'd construct a matrix showing which
   patches modified which files.
3) If any files are modified by more than one patch, I'd read the
   patch files to see where the modifications are being made.
4) If more than one patch modifies the same original qmail code, I'd
   strongly consider dropping one of the patches or finding a
   competent programmer to merge them. This could be tricky and/or a
   lot of work.
5) Use "patch" to install non-conflicting patches.
6) Manually install conflicting and failed patches.
7) Build qmail per INSTALL and patch-specific instructions.
8) Test, test, test.
9) Test some more, but still expect the unexpected.

-Dave

patching qmail with multiple patches

[reach_prashant]

  hello friends 


  i am trying to apply following patches on qmail-1.03 , but not able to
apply all those 

  1> qmail-bounce.patch
  2> qmail-ldap-2601.patch
  3> patching dns.c  with appropriate patch 
  4> qmail-big-concurrency.patch 
  5> qmail-big-todo. patch  


is there any one who had applied all these patches on qmail-1.03 , if
so , then please guide me in which sequence  i  have to apply these patches
, i have tried many permutations and combinations for applying these
patches but  its not happening for me , 

 it gives (after patching qmail-with 2-3 patches) already applies, want to
recurse  "-R"  etc , i dont know the exact messages but it was similliar to
these 



 thanks 
 Prashant Desai 

Re: Problem building qmail from qmail-1.03+patches-14.src.rpm

[Chris, the Young One]

On Fri, Jul 28, 2000 at 11:33:32PM +1000, Adrian Head wrote:
! The only thing I have changed was the following lines in the SPEC file
! to get around the FD_SET() problem with only 1024 descriptors in my
! kernel.

Rereading Adrian's message, I now see what's being said. Basically,
``ulimit -n'' was much higher than 1024, and the RPM script failed
to recognise that, and so Adrian set conf-spawn manually.

So, I take back what I said in the last message.

---Chris K.
-- 
 Chris, the Young One |_ Never brag about how your machines haven't been 
  Auckland, New Zealand |_ hacked, or your code hasn't been broken. It's 
http://cloud9.hedgee.com/ |_ guaranteed to bring the wrong kind of 
 PGP: 0xCCC6114E/0x706A6AAD |_ attention. ---Neil Schneider 

Re: Problem building qmail from qmail-1.03+patches-14.src.rpm

[Chris, the Young One]

On Fri, Jul 28, 2000 at 11:33:32PM +1000, Adrian Head wrote:
! /var/tmp/rpm-tmp.99466: /tmp/qmail-root/usr/bin/make-owners: Permission
! denied
! 
! What I don't understand is why the permission problem or the real
! function of make-owners.

Just a stab in the dark, but is it possible that your /tmp is mounted
with the ``noexec'' option?

! The only thing I have changed was the following lines in the SPEC file
! to get around the FD_SET() problem with only 1024 descriptors in my
! kernel.

A cursory glance at the Linux 2.2 source code doesn't show any way to
override the kernel limit of 1024 file descriptors (for select(); poll()
doesn't have this limitation, but qmail doesn't use poll() yet). See
.

If I remember correctly, even if you hack the kernel source to allow
an fd_set greater than 1024 bits, you still have to change the libc
header  (and possibly others).

---Chris K.
-- 
 Chris, the Young One |_ If you can't afford a backup system, you can't 
  Auckland, New Zealand |_ afford to have important data on your computer. 
http://cloud9.hedgee.com/ |_ ---Tracy R. Reed  
 PGP: 0xCCC6114E/0x706A6AAD |_ 

Problem building qmail from qmail-1.03+patches-14.src.rpm

[Adrian Head]

If this is Off Topic for this mailing list I apologise - please point me
in the right direction.  
I have this little problem that has been bugging me for a few days with
the installation of Bruce Guenter's qmail-1.03+patches-14.src.rpm from
http://em.ca/~bruceg/qmail+patches/

When building the binary RPM from the source I get the following error
from the install script as per the screen dump below.

[root@hercules SPECS]# rpm -ba qmail-1.03+patches.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.61330
.
[Cut]  (everything here looks OK to me)
.
/usr/src/redhat/BUILD/qmail-1.03
+ /tmp/qmail-root/usr/bin/make-owners /tmp/qmail-root/etc/qmail
/var/tmp/rpm-tmp.99466: /tmp/qmail-root/usr/bin/make-owners: Permission
denied
Bad exit status from /var/tmp/rpm-tmp.99466 (%install)

What I don't understand is why the permission problem or the real
function of make-owners.

The permissions of the various files (dirs) are listed below just in
case:
[root@hercules SPECS]# ll /tmp/qmail-root/usr/bin/make-owners 
-rwxr-xr-x1 root qmail 720 Jul 28 23:05
/tmp/qmail-root/usr/bin/make-owners
[root@hercules SPECS]# ls -lah /tmp/qmail-root/etc/qmail  
total 6.0k
drwxr-xr-x6 root qmail1.0k Jul 28 23:05 .
drwxr-xr-x7 root root 1.0k Jul 28 23:05 ..
drwxr-sr-x2 aliasqmail1.0k Jul 28 23:05 alias
drwxr-xr-x2 root qmail1.0k Jul 28 23:05 control
drwxr-xr-x2 root qmail1.0k Jul 28 23:05 owners
drwxr-xr-x2 root qmail1.0k Jul 28 23:05 users

The only thing I have changed was the following lines in the SPEC file
to get around the FD_SET() problem with only 1024 descriptors in my
kernel.
#fds=`ulimit -n`
#let spawnlimit='(fds-6)/2'
#echo $spawnlimit >conf-spawn
echo 400 >conf-spawn

./chkspawn
Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.
This means that the qmail daemons could crash if you set the run-time
concurrency higher than 509. So I'm going to insist that the concurrency
limit in conf-spawn be at most 509. Right now it's 44997.
make: *** [spawn.o] Error 1
Bad exit status from /var/tmp/rpm-tmp.72813 (%build)

The machine is RH6.2 minimal install
Linux hercules.local 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686
unknown

I'm not a member of this mailing list so could any correspondence be
emailed directly please.  If anyone else has had a simular problem and
have "it worked for me" solutions then they would be much appreciated. 

Thanks for your time

Adrian Head

Updated location for qmail spam patches ?

[Marc ter Horst]

Hi,

I noticed the ftp location for the updated (to 1.03) anti-spam 
patches from Ras/Lionel/Lindsay doesn't allow anon access 
anymore (it's a buggy wu-ftpd version ?). Anyway, can anyone 
point me to a new location, update the web site, or send me a 
copy ?

Thanks,

Marc
 
Marc J.J. ter HorstP.O. Box 930  Phone   : +31 318 557237
Manager ICT 3900 AX Veenendaal   fax : +31 318 550485
Nucletron The NetherlandsInternet: [EMAIL PROTECTED] 
  

Re: VRFY patches

[Robert Varga]

Ok, problem solved. They are not using VRFY, only the error messages were
suggesting that they are using. And they have been doubly confusing since
the error message was:

Vrfy failed on all MXes.

The problem was that I put only an A record for the zone and no MX
records. The mailcheck went on correctly, since the zone name had
an MTA on it, however there were no MXes and the check failed. Naturally
they did not state in the zone expectations that MX record should be
present, only that mail should be deliverable to postmaster@zone.

Regards,

Robert Varga

On Thu, 15 Jun 2000, Robert Varga wrote:

> 
> 
> On Thu, 15 Jun 2000, Petr Novotny wrote:
> 
> > 
> > What's wrong with 252? It's also a positive query. Please test it 
> > yourself:
> > telnet localhost 25
> > ...
> > VRFY postmaster
> > 252 send some mail, i'll try my best
> > QUIT
> 
> The problem is that the zone check gave back an error to me and I don't
> maintain the zone check, therefore I cannot make them register the zone
> this way.
> 
> > 
> > > since the domain
> > > registration policy in our country states that the domains to be
> > > registered must pass a verification script and the script checks for
> > > the existence of the postmaster user on all MX-es.
> > 
> > How do they test existence? 252 is "user exists" (or "maybe"), 
> > according to RFC.
> > 
> 
> I don't know how they test, the only thing I know is that qmail is setup
> to receive the mails for the domain, the test is with VRFY, and the test 
> gives back an error. Sendmail returned 250
>  for the query and it worked that way, so
> the only thing I think to be checked is the status code. 
> 
> And correct me if I am mistaken, but the only thing which should be
> checked is the status code anyway.
> 
> Regards,
> 
> Robert Varga
> 
> 

Re: VRFY patches

[Petr Novotny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15 Jun 00, at 14:27, Robert Varga wrote:

> 
> > What's wrong with 252? It's also a positive query. Please test it
> > yourself: telnet localhost 25 ... VRFY postmaster 252 send some
> > mail, i'll try my best QUIT
> 
> The problem is that the zone check gave back an error to me and I
> don't maintain the zone check, therefore I cannot make them register
> the zone this way.

In that case, their test is broken. End of story. "252" means yes.

> > How do they test existence? 252 is "user exists" (or "maybe"),
> > according to RFC.
> > 
> 
> I don't know how they test, the only thing I know is that qmail is
> setup to receive the mails for the domain, the test is with VRFY, and
> the test gives back an error. Sendmail returned 250
>  for the query and it worked that way,
> so the only thing I think to be checked is the status code. 

Any code starting with "2" means OK. RFC821.

> And correct me if I am mistaken, but the only thing which should be
> checked is the status code anyway.

If you really need that, just change that 252 to 250. But, honestly, I 
think you're solving a problem which does not exist.

-BEGIN PGP SIGNATURE-
Version: PGP 6.0.2 -- QDPGP 2.60 
Comment: http://community.wow.net/grt/qdpgp.html

iQA+AwUBOUi+5lMwP8g7qbw/EQKFYgCWN04DbtMC/GWrOVgIT0aZ9iu6ygCfcdAm
RYe2DhZHfUChlsw5q/ASU2M=
=c97F
-END PGP SIGNATURE-
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
 [Tom Waits]

Re: VRFY patches

[Robert Varga]

On Thu, 15 Jun 2000, Petr Novotny wrote:

> 
> What's wrong with 252? It's also a positive query. Please test it 
> yourself:
> telnet localhost 25
> ...
> VRFY postmaster
> 252 send some mail, i'll try my best
> QUIT

The problem is that the zone check gave back an error to me and I don't
maintain the zone check, therefore I cannot make them register the zone
this way.

> 
> > since the domain
> > registration policy in our country states that the domains to be
> > registered must pass a verification script and the script checks for
> > the existence of the postmaster user on all MX-es.
> 
> How do they test existence? 252 is "user exists" (or "maybe"), 
> according to RFC.
> 

I don't know how they test, the only thing I know is that qmail is setup
to receive the mails for the domain, the test is with VRFY, and the test 
gives back an error. Sendmail returned 250
 for the query and it worked that way, so
the only thing I think to be checked is the status code. 

And correct me if I am mistaken, but the only thing which should be
checked is the status code anyway.

Regards,

Robert Varga

Re: VRFY patches

[Petr Novotny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15 Jun 00, at 14:12, Robert Varga wrote:

> I need qmail to answer with a status code of 250 for VRFY
> command when it is querying
> postmaster@

What's wrong with 252? It's also a positive query. Please test it 
yourself:
telnet localhost 25
...
VRFY postmaster
252 send some mail, i'll try my best
QUIT

> since the domain
> registration policy in our country states that the domains to be
> registered must pass a verification script and the script checks for
> the existence of the postmaster user on all MX-es.

How do they test existence? 252 is "user exists" (or "maybe"), 
according to RFC.

-BEGIN PGP SIGNATURE-
Version: PGP 6.0.2 -- QDPGP 2.60 
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBOUi721MwP8g7qbw/EQIDFQCgtX2l4yoWaYOmpMyZmC9aFbr6e8EAn030
S3maAzeLPsp4HHmjzvzZKg5r
=/sO9
-END PGP SIGNATURE-
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
 [Tom Waits]

Re: VRFY patches

[Robert Varga]

Or even a 250 for postmaster@* would be ok.

Regards,

Robert Varga

On Thu, 15 Jun 2000, Robert Varga wrote:

> 
> Hello,
> 
> I am searching a patch for a minimal support for VRFY.
> 
> I need qmail to answer with a status code of 250 for VRFY
> command when it is querying postmaster@
> since the domain registration policy in our country states that the
> domains to be registered must pass a verification script and the script
> checks for the existence of the postmaster user on all MX-es.
> 
> Is there some patch which can provide this functionality?
> 
> Regards,
> 
> Robert Varga
> 
> 

VRFY patches

[Robert Varga]

Hello,

I am searching a patch for a minimal support for VRFY.

I need qmail to answer with a status code of 250 for VRFY
command when it is querying postmaster@
since the domain registration policy in our country states that the
domains to be registered must pass a verification script and the script
checks for the existence of the postmaster user on all MX-es.

Is there some patch which can provide this functionality?

Regards,

Robert Varga

Re: big-* patches and FD_SET()

[Petr Novotny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15 Jun 00, at 12:07, clemensF wrote:

> what's that jazz with magic 509?  what does this number mean?

The largest number N such that 2*N+5<1024. (1024 being system 
limit on select() call and 2*N+5 being the maximum number of 
handles qmail at concurrency N uses.)

-BEGIN PGP SIGNATURE-
Version: PGP 6.0.2 -- QDPGP 2.60 
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBOUidh1MwP8g7qbw/EQJebQCfV0Mjw1EykcNzxY7+ou1ZTYNEYikAni2M
te2GrFuEQI8DhPTlxZpvHrnL
=BIbi
-END PGP SIGNATURE-
--
Petr Novotny, ANTEK CS
[EMAIL PROTECTED]
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
 [Tom Waits]

Re: big-* patches and FD_SET()

[clemensF]

> Toens Bueker:

> more than 509 available for a busy server.

what's that jazz with magic 509?  what does this number mean?

clemens

Re: big-* patches and FD_SET()

[Toens Bueker]

clemensF <[EMAIL PROTECTED]> wrote:

> > ./chkspawn
> > Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.
> 
> does qmail really take up that many fd's at a time?

Depends from what you're trying to do.
I just checked - sending 200 mails to one of our mail
servers (which is a little bit slow) took about 150
'qmail-remotes'. 

As there are at least 2 fds needed for each mail (and
there should be a few left for the OS), there should be
more than 509 available for a busy server.

By
Töns
-- 
Linux. The dot in /.

Re: big-* patches and FD_SET()

[Toens Bueker]

Russ Allbery <[EMAIL PROTECTED]> wrote:

> >> How can I increase this 'hidden limit'? 
> 
> > You can try what is described in /usr/include/sys/select.h, but i don't
> > know whether this will do something good: The C library might know too
> > much about the 1024 internally.
> 
> Raising the limit in this fashion is supported and should work correctly
> for Solaris 7 or later, IIRC.  It's a Solaris-specific hack, though.
> (Solaris, being a SysV derivative, really wants you to convert your
> software to use poll instead of select.)

That's what squid does. So qmail uses select, right?

By
Töns 
-- 
Linux. The dot in /.

Re: big-* patches and FD_SET()

[Peter van Dijk]

On Wed, Jun 14, 2000 at 10:42:21PM +0200, clemensF wrote:
> > Toens Bueker:
> 
> > ./chkspawn
> > Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.
> 
> does qmail really take up that many fd's at a time?

It needs 2 for every remote delivery, for example. One fd is passed by
qmail-rspawn to qmail-remote, being an open fd to the queue file, another
fd is needed for the connection to the remote host.

I figure local deliveries might need even more at times, but I may be wrong
here :)

Greetz, Peter.
-- 
[EMAIL PROTECTED] - Peter van Dijk [student:developer:madly in love]

Re: big-* patches and FD_SET()

[clemensF]

> Toens Bueker:

> ./chkspawn
> Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.

does qmail really take up that many fd's at a time?

clemens

Re: big-* patches and FD_SET()

[Russ Allbery]

Uwe Ohse <[EMAIL PROTECTED]> writes:
> On Wed, Jun 14, 2000 at 11:58:20AM +0200, Toens Bueker wrote:
 
>> How can I increase this 'hidden limit'? 

> You can try what is described in /usr/include/sys/select.h, but i don't
> know whether this will do something good: The C library might know too
> much about the 1024 internally.

Raising the limit in this fashion is supported and should work correctly
for Solaris 7 or later, IIRC.  It's a Solaris-specific hack, though.
(Solaris, being a SysV derivative, really wants you to convert your
software to use poll instead of select.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: big-* patches and FD_SET()

[Uwe Ohse]

On Wed, Jun 14, 2000 at 11:58:20AM +0200, Toens Bueker wrote:

> ./chkspawn
> Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.

edit qmail-1.03/conf-spawn, set the value to a number less then or 
equal to 509.

 
> How can I increase this 'hidden limit'? 

You can try what is described in /usr/include/sys/select.h, but i
don't know whether this will do something good: The C library 
might know too much about the 1024 internally.

Regards, Uwe

big-* patches and FD_SET()

[Toens Bueker]

Hi *,

I'm sure it's an FAQ but I haven't found any hints on this
until now.

>From my days with squid (http://squid.nlanr.net/), I
tought I'd now how to increase the filedescriptor limit on
Solaris. 

For qmail I did the same (edit /etc/system and add 'set
rlim_fd_max = 4096').

But I still cannot compile qmail with the big-* patches,
because they still complain, that:

./chkspawn
Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.

How can I increase this 'hidden limit'? 

root@blub:/usr/local/src/qmail/qmail-1.03> ulimit -a
core file size (blocks) unlimited
data seg size (kbytes)  unlimited
file size (blocks)  unlimited
open files  2048
pipe size (512 bytes)   10
stack size (kbytes) 8192
cpu time (seconds)  unlimited
max user processes  15941
virtual memory (kbytes) unlimited

Any hints?

Thx

By
Töns
-- 
Linux. The dot in /.

Re: qmail+patches RPM + logging

[Christian Wiese]

Hi Peter,

thank you very much for your help.
Now the logging mechanism is working nice.

Thanks

Christian

Peter Green schrieb:

> also sprach cw:
> > Hi all,
> >
> > for my previous qmail installations I used the "Memphis" RPMS.
> > Today I've tried to setup a qmail server with the latest qmail+patches
> > RPM from Bruce.
> > The base system is up and running, but I can't find any logfiles.
> > Where can I find some logfiles ?
> > Could somebody explain me the logging machanism.
>
> You could also ask this on the rpms mailing list Bruce has set up for this
> application. Send mail to <[EMAIL PROTECTED]> to subscribe.
>
> Anyhoo, the default for the RPM is to use splogger. This sends log entries
> to syslog for processing.
>
> To set it up differently, you have two options:
>
> 1) <http://em.ca/~bruceg/qmail+patches/loggers/> Choose your preferred
> logging method and install the appropriate RPM. I don't do this so I can't
> help much beyond this...
>
> 2) Put your desired logging mechanism in /var/qmail/control/logger and it
> will be used instead of splogger. I have the following in mine:
>
>   /usr/bin/multilog t s10 /var/log/{}
>
> This sticks the multilog entries in /var/log/SERVICE, where SERVICE is
> `qmail', `pop3d', `smtpd', or whatever.
>
> HTH!
>
> /pg
> --
> Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED]
> ---
> > : Any porters out there should feel happier knowing that DEC is shipping
> > : me an AlphaPC that I intend to try getting linux running on: this will
> > : definitely help flush out some of the most flagrant unportable stuff.
> > : The Alpha is much more different from the i386 than the 68k stuff is, so
> > : it's likely to get most of the stuff fixed.
> >
> > It's posts like this that almost convince us non-believers that there
> > really is a god.
> (A follow-up by [EMAIL PROTECTED], Anthony Lovell, to Linus's
> remarks about porting)

Re: qmail+patches RPM + logging

[Peter Green]

also sprach cw:
> Hi all,
> 
> for my previous qmail installations I used the "Memphis" RPMS.
> Today I've tried to setup a qmail server with the latest qmail+patches
> RPM from Bruce.
> The base system is up and running, but I can't find any logfiles.
> Where can I find some logfiles ?
> Could somebody explain me the logging machanism.

You could also ask this on the rpms mailing list Bruce has set up for this
application. Send mail to <[EMAIL PROTECTED]> to subscribe.

Anyhoo, the default for the RPM is to use splogger. This sends log entries
to syslog for processing.

To set it up differently, you have two options:

1) <http://em.ca/~bruceg/qmail+patches/loggers/> Choose your preferred
logging method and install the appropriate RPM. I don't do this so I can't
help much beyond this...

2) Put your desired logging mechanism in /var/qmail/control/logger and it
will be used instead of splogger. I have the following in mine:

  /usr/bin/multilog t s10 /var/log/{}

This sticks the multilog entries in /var/log/SERVICE, where SERVICE is
`qmail', `pop3d', `smtpd', or whatever.

HTH!

/pg
-- 
Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED]
---
> : Any porters out there should feel happier knowing that DEC is shipping
> : me an AlphaPC that I intend to try getting linux running on: this will
> : definitely help flush out some of the most flagrant unportable stuff.
> : The Alpha is much more different from the i386 than the 68k stuff is, so
> : it's likely to get most of the stuff fixed.
>
> It's posts like this that almost convince us non-believers that there
> really is a god.
(A follow-up by [EMAIL PROTECTED], Anthony Lovell, to Linus's
remarks about porting)

qmail+patches RPM + logging

[Christian Wiese]

Hi all,

for my previous qmail installations I used the "Memphis" RPMS.
Today I've tried to setup a qmail server with the latest qmail+patches
RPM from Bruce.
The base system is up and running, but I can't find any logfiles.
Where can I find some logfiles ?
Could somebody explain me the logging machanism.

Thanks

Christian

Re: Anyone running TLS and SMTP AUTH patches?

[listy-dyskusyjne Krzysztof Dabrowski]

>I applied the TLS patch, then the auth patch, which required some
>handwork. If you can't figure it out, I can send you some diffs.
>
>-Dave

Dave.. if you can, then send this patch to me so i can add it to my 
webpage. Maybe it'll be helpfull for others too.

Kris

Re: Anyone running TLS and SMTP AUTH patches?

[Dave Sill]

Jason Haar <[EMAIL PROTECTED]> wrote:

>... I simply cannot get them to patch together. With one in place the other
>causes humungous amounts of rejected patches.
>
>Has anyone made a "merged" patch of these two?
>
>http://www.elysium.pl/members/brush/qmail-smtpd-auth/
>http://www.esat.kuleuven.ac.be/~vermeule/qmail/tls.patch

I applied the TLS patch, then the auth patch, which required some
handwork. If you can't figure it out, I can send you some diffs.

-Dave

Anyone running TLS and SMTP AUTH patches?

[Jason Haar]

... I simply cannot get them to patch together. With one in place the other
causes humungous amounts of rejected patches.

Has anyone made a "merged" patch of these two?

http://www.elysium.pl/members/brush/qmail-smtpd-auth/
http://www.esat.kuleuven.ac.be/~vermeule/qmail/tls.patch

Thanks

-- 
Cheers

Jason Haar

Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417
   

New qmail-MySQL patches

[Iain Patterson]

  Expanding on the work of the infamous [EMAIL PROTECTED] 
(infamous, that is, because no-one knows his real name :), I have 
come up with a set of patches to qmail and checkpassword that let 
you have virtual POP3 users in a MySQL database.  For more details 
hop over to http://iain.cx/unix/qmail/mysql.php, just don't mention 
the invisible menus and headings - I'm having a problem with libttf.

-- blurb follows --
  Why would you want to use my patches over takeshi's?  Because 
you can do more stuff.  Everything that qmail and checkpassword do 
that's related to local mail delivery can be stored in the database.  
This means virtual domains (rewriting [EMAIL PROTECTED] to 
[EMAIL PROTECTED]), receipt hosts (rcpthosts table complements 
control/rcpthosts), .qmail aliases (associating alias-root 
with the virtual user "mail4root"), mail(dir|box) ownership 
(qmail-getpw bigcompany-sales returns 
bigcompany\0800\0100\0/popmail/bigcompany\0-\0sales\0) and POP3 
authentication (bigcompany can read mail).  The latter can use 
encrypted, MySQL-hashed or plaintext passwords.

  You can also do crazy things with judicious database hacking, 
including giving real system users separate POP3 passwords by 
putting their real uid, gid and home directory in the mailbox 
table (haha, they may sniff my mail password but they still can't 
login as me via ssh) and have mailing lists by putting several 
entries in the alias table.  I admit I need to document this 
more: documentation is work-in-progress at the minute but there 
is at least something on the web page.

  Perhaps the most significant feature is that I've tried to 
stay in the qmail spirit by providing loads of error checking so 
for example if the MySQL server goes down (and we all know that 
they don't) or if we can't alloc our strallocs, the various tools 
will return 111 and try again later.  Please audit my code and 
tell me if I'd made any howlers.

  All of this has been tested on Linux 2.2.1[024] and 
FreeBSD 3.[13] but feedback is always welcome.
-- blurb precedes --
-- 
#include  /* #include  ? */
int main() { struct in_addr *c = malloc(5);
inet_aton("73.97.105.110", c); printf("%s\n", c); }

Re: Good patches to apply to new installations?

[John Gonzalez/netMDC admin]

On Mon, 17 Jan 2000, Niall R. Murphy wrote:
>   >I personally use vanilla qmail.  It is -not- necessary to patch
>   >it.
> 
>I was under the impression bigdns allowed qmail to send to sites that it
>would otherwise have problems resolving MX for?
>
>Niall

This problem is very picky about the machines it crops up on. Some people
claim that linux has this problem, while both of my linux systems do not
have the patch and have never had an issue.

The LWQ mail page goes into detail with a description of the problem, and
really, the only advice is to check your log files often and if you see
the problem, then patch. If it aint broke, dont fix it. Also (i havent
verified this) but i have heard that AOL recently is under the byte limit,
so this may no longer be a problem (but there might be others not under
the limit, who knows)

  ___   _  __   _  
__  /___ ___    /__  John Gonzalez/Net.Tech
__  __ \ __ \  __/_  __ `__ \/ __  /_  ___/ MDC Computers/netMDC!
_  / / / `__/ /_  / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052
/_/ /_/\___/\__/ /_/ /_/ /_/\__,_/  \___/ http://www.netmdc.com
[-[system info]---]
 10:50am  up 178 days, 21:09,  5 users,  load average: 0.09, 0.20, 0.16

Re: Good patches to apply to new installations?

[Walt Mankowski]

On Mon, Jan 17, 2000 at 01:07:56PM +0100, Hans Sandsdalen wrote:
> vanilla qmail? What is that? And where di I find it?

"Vanilla" is an English expression meaning that it's just the plain,
unaltered version.  I believe it has its origin in ice cream flavors.
You can order "plain vanilla", or vanilla with nuts, vanilla with
fudge ripple, vanilla with chocolate chip cookie dough, etc.

Re: Good patches to apply to new installations?

[Hans Sandsdalen]

"Niall R. Murphy" wrote:
> 
>>I personally use vanilla qmail.  It is -not- necessary to patch
>>it.
> 
> I was under the impression bigdns allowed qmail to send to sites that it
> would otherwise have problems resolving MX for?
> 
> Niall
> --
> Niall Richard Murphy: System Operator, Ireland On-Line
> --
> They said, "You have a blue guitar / You do not play things as they are."
> The man replied, "Things as they are / Are changed upon the blue guitar."
>---Wallace Stevens

vanilla qmail? What is that? And where di I find it?
-- 
/hans

Re: Good patches to apply to new installations?

[Niall R. Murphy]

   >I personally use vanilla qmail.  It is -not- necessary to patch
   >it.
 
I was under the impression bigdns allowed qmail to send to sites that it
would otherwise have problems resolving MX for?

Niall
-- 
Niall Richard Murphy: System Operator, Ireland On-Line
--
They said, "You have a blue guitar / You do not play things as they are."
The man replied, "Things as they are / Are changed upon the blue guitar."
   ---Wallace Stevens

Good patches to apply to new installations?

[Niall R. Murphy]

Hi folks,

I'm wondering if there's a recommended list of patches that should be
applied to any new qmail installation. I have unpacked Bruces' RPM
and looked at the patch list there, and from those it seems as if
the following should be applied to any installation:

big-dns
big-todo
bind-interface

and possibly

conredirect
queuevar
showctl
bounce [limit bounce size]
tls

and syncdir for Linux systems.

Anyone know if these might make their way into an intermediate
release of qmail, before 2.0 ?

Thanks,
Niall
-- 
Niall Richard Murphy: System Operator, Ireland On-Line
--
They said, "You have a blue guitar / You do not play things as they are."
The man replied, "Things as they are / Are changed upon the blue guitar."
   ---Wallace Stevens

Re: The Canonical Set of qmail Patches

[Aaron Nabil]

On Sun, 2 Jan 2000, Russell Nelson wrote:

> listy-dyskusyjne Krzysztof Dabrowski writes:
>  > Why can't we make something like this (qmail-whatever)?
>  > This way we can port all the exisiting patches that everyone is applying 
>  > these days into one bit patch
>  > and later on supporters can work off this patch to add more feautres?
>  > Applying a lot of patches to qmail these days leads me into reading diffs 
>  > manualy and adding them by hand.
>  > 
>  > Is this idea anything good in your opinion?
> 
> Sure.  Propose a canonical set of patches.  About the only thing I
> install, and only on very high volume sites, is big-todo.  Oh, and the
> rblsmtpd multiple -r option patch.  Given that MAPS
> (http://mail-abuse.org) has adopted the DUL and RSS zones, you really
> need multiple zones.  And running multiple copies of rblsmtpd (Dan's
> suggested solution) is too much of a hack, given the simplicity of
> Aaron Nabil's patch.

Cool, thanks!  I like being useful. :)

But I was a bit surprised that you overlooked my POP "stat" bug on your
page, since qmail has so few (if any) other bugs, I was kinda expecting it
to get better billing. (maybe even it's own category and little box like
all the other categories!)  It isn't even mentioned!  Considering how much
a bug like that could screw up a email client, I'd certainly put it (and
the big-dns thing) into the "must patch" category.

It still lives at http://www.spiritone.com/~nabil/popstatbug.diff and
a search of the archives would turn up some explanatory material, in case
anyone needs it.  


--
Aaron Nabil

Re: The Canonical Set of qmail Patches

[Fred Lindberg]

On Sun,  2 Jan 2000 23:17:51 -0500 (EST), Russell Nelson wrote:

>Sure.  Propose a canonical set of patches.  About the only thing I
>install, and only on very high volume sites, is big-todo.  Oh, and the
>rblsmtpd multiple -r option patch.  Given that MAPS

and the big-concurrency patch. Seems to hurt very little even with
concurrency << 255.

-Sincerely, Fred

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

Re: The Canonical Set of qmail Patches

[bert hubert]

On Sun, Jan 02, 2000 at 11:17:51PM -0500, Russell Nelson wrote:

> Sure.  Propose a canonical set of patches.  About the only thing I
> install, and only on very high volume sites, is big-todo.  Oh, and the
> rblsmtpd multiple -r option patch.  Given that MAPS

And big-dns, I hope.

Regards,


bert hubert.

-- 
+---+  |  http://www.rent-a-nerd.nl
| nerd for hire |  |  
+---+  | - U N I X -
|  |  Inspice et cautus eris - D11T'95

The Canonical Set of qmail Patches

[Russell Nelson]

listy-dyskusyjne Krzysztof Dabrowski writes:
 > Why can't we make something like this (qmail-whatever)?
 > This way we can port all the exisiting patches that everyone is applying 
 > these days into one bit patch
 > and later on supporters can work off this patch to add more feautres?
 > Applying a lot of patches to qmail these days leads me into reading diffs 
 > manualy and adding them by hand.
 > 
 > Is this idea anything good in your opinion?

Sure.  Propose a canonical set of patches.  About the only thing I
install, and only on very high volume sites, is big-todo.  Oh, and the
rblsmtpd multiple -r option patch.  Given that MAPS
(http://mail-abuse.org) has adopted the DUL and RSS zones, you really
need multiple zones.  And running multiple copies of rblsmtpd (Dan's
suggested solution) is too much of a hack, given the simplicity of
Aaron Nabil's patch.

-- 
-russ nelson <[EMAIL PROTECTED]>  http://russnelson.com
Crynwr sells support for free software  | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | do for you..."  -Perry M.

Re: qmail-1.03+patches-8.src.rpm

[Bruce Guenter]

On Thu, Dec 02, 1999 at 09:31:32AM +0100, Hans Sandsdalen wrote:
> when I run "rpm --rebuild qmail-1.03+patches-8.src.rpm"
> the process stops with:
> 
> + PATH=/sbin:/usr/sbin:/bin:/usr/bin
> /var/tmp/rpm-tmp.2: line 168: syntax error: unexpected end of file
> Bad exit status from /var/tmp/rpm-tmp.2 (%install)

I have just put release 10 of the above SRPM onto my web site at:
    http://em.ca/~bruceg/qmail+patches/
It fixes this syntax error along with adding integration with the new
daemontools package.
-- 
Bruce Guenter <[EMAIL PROTECTED]>   http://em.ca/~bruceg/

qmail-1.03+patches-8.src.rpm

[Hans Sandsdalen]

Hi

when I run "rpm --rebuild qmail-1.03+patches-8.src.rpm"
the process stops with:

nroff -man envelopes.5 > envelopes.0
nroff -man forgeries.7 > forgeries.0
+ ./compile qmail-pipe.c
+ ./load qmail-pipe
+ exit 0
Executing: %install
+ umask 022
+ cd /usr/src/RPM/BUILD
+ cd qmail-1.03
+ export PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
/var/tmp/rpm-tmp.2: line 168: syntax error: unexpected end of file
Bad exit status from /var/tmp/rpm-tmp.2 (%install)


Any idea what's wrong??


$ rpm -qa | grep "^rpm-"
rpm-devel-3.0.3-31mdk
rpm-3.0.3-31mdk

$ uname -a
Linux naiad.spacetec.no 2.2.13-22mdk #1 SMP Fri Oct 22 02:06:33 CEST
1999 i686 unknown
-- 
/hans

qmail-1.03+patches-8.src.rpm

[Hans Sandsdalen]

Hi

when I run "rpm --rebuild qmail-1.03+patches-8.src.rpm"
the process stops with:

nroff -man envelopes.5 > envelopes.0
nroff -man forgeries.7 > forgeries.0
+ ./compile qmail-pipe.c
+ ./load qmail-pipe
+ exit 0
Executing: %install
+ umask 022
+ cd /usr/src/RPM/BUILD
+ cd qmail-1.03
+ export PATH=/sbin:/usr/sbin:/bin:/usr/bin
+ PATH=/sbin:/usr/sbin:/bin:/usr/bin
/var/tmp/rpm-tmp.2: line 168: syntax error: unexpected end of file
Bad exit status from /var/tmp/rpm-tmp.2 (%install)


Any idea what's wrong??
-- 
/hans

Patches for badmailfrom and RCPT max qty

[Martin Paulucci]

Hi all,

In that case, where is the patch, and also, anybody knows where can I find
a patch to use wildcards in the badmailfrom /var/qmail/control file, so I
can put for example: admin__@* or something like that. Nicolas told me
there was one.

Thanks!



Anand Buddhdev escribio:

> On Thu, Nov 11, 1999 at 07:33:19AM -0500, Russell Nelson wrote:
> 
> > Andres Mendez writes:
> >  > Where is the new qmail-1.03-maxrcpt.patch?
> > 
> > Not needed.  qmail-smtpd respects the number in control/databytes .
> 
> I think he means the patch which limits the number of RCPT's a client
> can issue to qmail-smtpd, not the size of a message.
> 
> -- 
> See complete headers for more info

RE: Qmail with LDAP Auth patches

[Jim Gilliver]

> > A small sample from the ldif file before I ldbm it:
> >
> > dn: cn=John Smith
> > cn: John Smith
> > sn: Smith
> > objectClass: qmailUser
> > objectClass: person
> > mail: [EMAIL PROTECTED]
> > mailHost: mail.budget.co.nz
> > mailMessageStore: /home/jsmith/Mailbox/
> > qmailUser: jsmith
> > qmailUID: 666
> > qmailGID: 666
> > uid: jsmith
> > userPassword: xxx


After hours and hours of messing around with source code and inserting all
sorts of debugging info that was never meant to be, I've found the problem,
and there's a small problem with the Qmail-LDAP documentation on the web
page.

In the example LDIF file, is says that mailMessageStore should be
/usr/home/opi/maildir/.  In my case, this appears to be wrong, as
qmail-pop3d attempts to chdir to the maildir provided on the command line,
which it is already in, courtesy of checkpassword.  I fixed the problem
completely by undoing all my changes and changing every occurrence of
mailMessageStore to exclude the Mailbox portion.


I'm a little disappointed that noone on the qmail-ldap list was even able to
reply to my query, much less help with this obviously minor screwup...  but
perhaps someone can benefit from my frustration.

Re: Qmail with LDAP auth patches

[Andre Oppermann]

Jim Gilliver wrote:
> 
> Anyone have experience with this?

It might be better to post this to the [EMAIL PROTECTED]
list. You'll see a lot more ldap fans there!

-- 
Andre

> I've set it up, and the LDAP service is definitely working...  when I use
> checkpassword on the server, with the command
> 
> qmail-popup localhost /qmail-1.03/checkpassword pwd
> 
> it authenticates me fine.  But when I move the checkpassword into the /bin
> directory and try to connect from another machine, it rejects me.  In this
> case, I'm using Outlook 2000, so all I get is a password box back in my face
> (ie: no helpful output) but I suspect that there wouldn't be much
> information returned anyway.
> 
> A small sample from the ldif file before I ldbm it:
> 
> dn: cn=John Smith
> cn: John Smith
> sn: Smith
> objectClass: qmailUser
> objectClass: person
> mail: [EMAIL PROTECTED]
> mailHost: mail.budget.co.nz
> mailMessageStore: /home/jsmith/Mailbox/
> qmailUser: jsmith
> qmailUID: 666
> qmailGID: 666
> uid: jsmith
> userPassword: xxx
> 
> the user password is using the same encryption scheme as the passwd file
> (DES?) and before you ask, yes, I do use maildirs called Mailbox...  it's
> from when I first setup qmail and was a bit confused when I copied and
> pasted some example lines into my startup files... suffice to say it's
> easier to leave it like that for now.
> 
> Anyway, I know the LDAP service works properly, and as I say, the manual
> checkpassword test works fine on the console, just apparently not from a
> client.  Any ideas anyone?

Qmail with LDAP auth patches

[Jim Gilliver]

Anyone have experience with this?

I've set it up, and the LDAP service is definitely working...  when I use
checkpassword on the server, with the command

qmail-popup localhost /qmail-1.03/checkpassword pwd

it authenticates me fine.  But when I move the checkpassword into the /bin
directory and try to connect from another machine, it rejects me.  In this
case, I'm using Outlook 2000, so all I get is a password box back in my face
(ie: no helpful output) but I suspect that there wouldn't be much
information returned anyway.

A small sample from the ldif file before I ldbm it:

dn: cn=John Smith
cn: John Smith
sn: Smith
objectClass: qmailUser
objectClass: person
mail: [EMAIL PROTECTED]
mailHost: mail.budget.co.nz
mailMessageStore: /home/jsmith/Mailbox/
qmailUser: jsmith
qmailUID: 666
qmailGID: 666
uid: jsmith
userPassword: xxx

the user password is using the same encryption scheme as the passwd file
(DES?) and before you ask, yes, I do use maildirs called Mailbox...  it's
from when I first setup qmail and was a bit confused when I copied and
pasted some example lines into my startup files... suffice to say it's
easier to leave it like that for now.

Anyway, I know the LDAP service works properly, and as I say, the manual
checkpassword test works fine on the console, just apparently not from a
client.  Any ideas anyone?

Re: Qmail.org webpage [Was Re: Patches revisited]

[Fred Lindberg]

On Mon, 13 Sep 1999 10:42:06 -0400, Thomas M. Sasala wrote:

>   For the qmail gurus, the page is great.  You scan down a single
>page, find the program you are looking for, and you run with it.  For

Exactly! Thanks, Russell!


-Sincerely, Fred

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

Qmail.org webpage [Was Re: Patches revisited]

[Thomas M. Sasala]

I must say, as a qmail newbie (and an email administrator newbie),
the qmail homepage was/is a bit daunting.  Heck, I still have 
trouble finding things I am looking for.  My problem is there is just
too much information.  When I first got started with qmail I followed
the
great Internet strategy: find a suitable program from the net, download
it, read INSTALL, make, make install :).  In combination with the 
install files and lwq, I managed to get things installed and working.
However, I think the only reason I managed to get it all to work was
by following the procedure in lwq.  Most of the things I did I have 
no idea what they do.  Moreover, after every step, it seems I had to 
go and download yet another tool/ultility to get the overall job done.

IMHO, there seems to be too much information on the main page.
For example, one of the first things I came across on the web page was
the documentation section.  In fact, the exact thing I was looking for.
However, the second link is how to configure selective relaying.  
Selective relaying; what the heck is that ;)  The next thing is 
the author's enhancement software.  Huh, where's the tar file.  Ah, it's
at the top of the page. okay.  Now, looking at the enhancement software,
what the heck is ezmlm?  Maildirs?  Where are the mbox's?  Get the point
here?  A lot of jargon for a newbie.  Heck, even if I had been an
administrator for the last 10 years, much of the information is very
qmail
specific (Maildir, checkpassword, daemontools, etc.).

For the qmail gurus, the page is great.  You scan down a single
page, find the program you are looking for, and you run with it.  For
someone who doesn't know a Maildir from a rcpthosts file, it's a bit
much.  I commend Russel on a concise, informative web page, but 
us newbies need something a little less concise and with a little less
information.

Thanks for listening.

-Tom


Cris Daniluk wrote:
> 
> I've been using qmail for a few years now and I find the qmail.org site to
> be a comprehensive and very useful place to get what I need. It is all on
> one page (albeit in somewhat of chaos, the new gif makes it workable) and
> has exactly what I need. Certainly don't change it :)
> 
> However, I think Lyndon's point may have validity in a small sense. All this
> information is obfuscating to new people to qmail, it is confusing enough as
> it is for someone moving from sendmail's trashy system. I think it would be
> GREAT to have an alternative place in a nice simple layout that explains
> things to people. The easier you make it to use, the more people will use it
> (though that doesn't explain why people use Sendmail's cryptic system :).
> 
> As far as I'm concerned, make the new site. Just don't change the current
> one in the process! To compliment Russ, it *is* much nicer having it all on
> one page. Time saving. I can also search for what I'm looking for.


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

RE: Patches revisited

[Cris Daniluk]

I've been using qmail for a few years now and I find the qmail.org site to
be a comprehensive and very useful place to get what I need. It is all on
one page (albeit in somewhat of chaos, the new gif makes it workable) and
has exactly what I need. Certainly don't change it :)

However, I think Lyndon's point may have validity in a small sense. All this
information is obfuscating to new people to qmail, it is confusing enough as
it is for someone moving from sendmail's trashy system. I think it would be
GREAT to have an alternative place in a nice simple layout that explains
things to people. The easier you make it to use, the more people will use it
(though that doesn't explain why people use Sendmail's cryptic system :).

As far as I'm concerned, make the new site. Just don't change the current
one in the process! To compliment Russ, it *is* much nicer having it all on
one page. Time saving. I can also search for what I'm looking for.

-Original Message-
From: Russell Nelson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 11, 1999 11:50 PM
To: QMail List
Subject: RE: Patches revisited


Lyndon Griffin writes:
 > It's easy to say something sucks.  It's hard to do something about it.
 > Let's do something about it.

Go ahead.  Make a suggestion for improvement.  Reiterating *why* it
sucks is not helpful.

--
-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!

RE: Patches revisited

[Russell Nelson]

Lyndon Griffin writes:
 > It's easy to say something sucks.  It's hard to do something about it.
 > Let's do something about it.

Go ahead.  Make a suggestion for improvement.  Reiterating *why* it
sucks is not helpful.

-- 
-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!

RE: Patches revisited

[Russell Nelson]

David Dyer-Bennet writes:
 > Also, there isn't much editorial content.  I can certainly see reasons
 > why, but what people really need is *advice* about how to proceed with
 > qmail, rather than a menu of everything that's available. 

Perhaps so, but without knowing what problems they're trying to solve, 
I can't give them good advice.  Nearly everyone wants a customized
solution.  If I give them all the information, they can create one for 
themselves.

-- 
-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!

Re: Patches revisited

[Ruben van der Leij]

On Fri, Sep 10, 1999 at 12:33:28PM -0700, Lyndon Griffin wrote:

> From the presentation of information perspective, the site is not all that
> good. 
> imagine that you and Dan Bernstein and countless others want it to be
> an even more powerful force.

One simple question. Have you *seen*, as in 'with your own eyes', the pages
Dan Bernstein has made?

It all boils down to the question of form versus function. *Anything* about
qmail chooses function. The tiniest detail like your SMTP-greeting has a
well chosen function. (Do NOT tell who you are and what version. It might
give people too much info..)

A fancy box, nice manual and slick webpages will not add *function*, just
form. 


-- 
Ruben

--

Eat more memory!

Re: Patches revisited

[Adam D . McKenna]

I think that it would be really useful if qmail.org had an "apps" section
similar to freshmeat.net or linuxapps.com.  If I could search through names
and decriptions of apps, that would be *very useful*.  For instance, if I
hear about this cool program called "vchkpw", that's an addition for qmail,
and I go to www.qmail.org, a simple search is not going to find it, because
the places that vchkpw is mentioned on the qmail page do not lead to the
actual software.  vchkpw is listed as the following:

>Christopher Johnson (EI39-1) wrote a virtual domains package with the
>following features. Inter7 is now maintaining the current version. 

For someone who searches for "virtual domains", this is fine.  However, if
I've used vchkpw before and just can't remember the link, then it's going to
be hard for me to find this on the page.  Especially since it's listed under
"Alternative checkpassword implementations."  It's obvious to you or me why
your checkpassword program relates to virtual domains, but that is not
obvious at all to a newbie.

Another thing that database searches are good for is that you can have
descriptions with words appearing out of order.  For instance, a search for
"virtual domains" will find a document with "virtual mail domains" as well.

Anyway, just my 2 cents.  I think the qmail page is definitely a very
valuable resource, but I can see how it would be confusing for newbies.

--Adam

RE: Patches revisited

[David Dyer-Bennet]

Lyndon Griffin <[EMAIL PROTECTED]> writes on 10 September 1999 at 13:53:56 -0700

 > Maybe it's subjective, but I disagree - I don't feel that the site is well
 > organized.  Yes, there are sections of seemingly related material, which I
 > guess is what you deem to be well organized.  I do agree with you that this
 > may no longer be the forum for this discussion.  As you all can probably
 > gather, I'm anxious to continue this discussion, however.

Well, if Russell wants to announce that he doesn't care to hear our
opinions, I could be convinced to cease offering them.  I'm hoping,
however, that a polite and detailed discussion of the site design may
help come up with some suggestions that would significantly improve
it, and if we do and since people seem to be willing to help, perhaps
could actually be implemented.

And nearly everything *is* subjective, I'm certainly with you there.

Let me start with a big *thank you* to Russell Nelson for creating the
site, and keeping it pretty current.  I've gone there a number of
times looking for specific things like the big dns patch, and I've
always found them.

Point 1: I find the categories things are grouped into somewhat
arbitrary.  In particular, I think somebody new to qmail would find
them very confusing.

[addons] 

Big -- and yet there are at least two or three others that are just
breakouts from here. 

[author's software] 

I think I see why these have a separate category -- BUT they're
essentially addons.

[qmail book] 
[commercial support] 

These two categories are clear and to the point.

[checkpassword] 

This is a particular class of addon, which newbies won't understand
the purpose of.  It's not even really for qmail as such.

[ezmlm] 

I guess it makes sense to break out this author-written addon into its
own section

[maildir] 

This is mostly glue for interfacing other things to maildir; so the
section title is reasonably appropriate.  

[tips] 

These are pretty useful; but are actually rather different from the
other sections it seems to me.

[user software] 

These are essentially addons too.

[user documentation] 

[high-volume servers] 

Another useful specialized category, I guess.

I wonder if what's really needed is a hierarchy more than 1 level
deep?  And maybe with some cross-referencing?

Also, there isn't much editorial content.  I can certainly see reasons
why, but what people really need is *advice* about how to proceed with
qmail, rather than a menu of everything that's available. 

Point 2: I think it would be nice if the front page had *less*
technical stuff, and in particular if it looked less like a large
collection of enhancements and fixes for things.  It presents the
appearance of a product that's in some disarray, which I think is an
unfortunate impression to make on a newcomer.

Point 3: I think I know why qmail.org is avoiding this role (time),
but it would be *really nice* if qmail.org laid out several paths into
qmail, with some discussion as to which path is appropriate for what
situation.  I suppose it's also possible that Russell just doesn't
want to take the abuse the putting specific recommended paths on
qmail.org is likely to generate (from a small minority).  (I don't
even know who is likely to object; it's just that I'm pretty sure
standing up is likely to get one shot at, as a general rule).  I'm
thinking of paths like "personal fully-connected server" and
"intermittently connected personal system" and "high-volume mail
sender" and "large POP user community" and "internal node in big
organization that uses qmail overall".  They wouldn't claim to be the
*only* or even *best* way -- but they'd describe a path and some of
the tradeoffs made.  This sort of thing would help new users *a lot* I
think.  I guess this is back to the "advice" concept I mentioned under
point 1. 
-- 
David Dyer-Bennet ***NOTE ADDRESS CHANGES***  [EMAIL PROTECTED]
http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon
http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms
Join the 20th century before it's too late!

RE: Patches revisited

[Lyndon Griffin]

> What do you want animated gifs and sound?
>
> - eric

Apparently, you neglected to read my previous post.  Simply having a link to
the list archive is not helpful.
>
> Lyndon Griffin escribió:
> >
> > >From the presentation of information perspective, the site is
> not all that
> > good.  Technically speaking, it is very good - fast loading,
> not a lot of BS
> > graphics, accessible with all browsers, including the elite few
> of us who
> > still use Lynx.  I am concerned about the quality and quantity of
> > information on the site.

Maybe it's subjective, but I disagree - I don't feel that the site is well
organized.  Yes, there are sections of seemingly related material, which I
guess is what you deem to be well organized.  I do agree with you that this
may no longer be the forum for this discussion.  As you all can probably
gather, I'm anxious to continue this discussion, however.

Re: Patches revisited

[Eric Dahnke]

Sorry for prolonging this most likely annoying thread, but I completely
disagree with you.

On the currentsite you've got simple access to qmail sources, man pages,
list archives, patches, support, etc and it is well organized. 

What do you want animated gifs and sound?

- eric

Lyndon Griffin escribió:
> 
> >From the presentation of information perspective, the site is not all that
> good.  Technically speaking, it is very good - fast loading, not a lot of BS
> graphics, accessible with all browsers, including the elite few of us who
> still use Lynx.  I am concerned about the quality and quantity of
> information on the site.  Certainly, QMail is a force in the industry, and I
> imagine that you and Dan Bernstein and countless others want it to be
> an even more powerful force.  QMail is making money, of that there can be no
> doubt.  Dan has a book deal, and you have a consultancy.  People that use
> QMail are also making money - Hotmail, Blue Mountain Arts, NetDynamics, for
> instance.  I like QMail, I want to continue to use QMail.  I want to be
> informed about QMail, and my previous experience from www.qmail.org is that
> it is not a place to get informed.  Yes, there is a patch list now on the
> page, and I applaud that effort.  I never would have looked if I hadn't been
> slammed, however, because I had already written off www.qmail.org as a
> dead-loss for information.
> 
> I know other people that have come away from the site with that same
> impression - even worse, I've had people tell me that the product must suck
> because the web site sucks.  I don't argue with them because - number one,
> I've had a lot of trouble getting to the information I want, number two
> image is everything.  It's the American Way, it's why companies advertise,
> and it's why people spend billions of dollars on the Internet.  QMail is not
> a product that can continue to stand on it's own merits - people obviously
> have a lot of trouble with it, just look at the volume on this mailing list.
> It's time that information about QMail becomes as robust as QMail itself.
> 
> Hearing from me that the site sucks shouldn't make you feel bad - after all,
> what do you know about me?  I'm certainly no guru on QMail, which is the
> foundation of my criticism for the QMail site.  There isn't a nice way to
> say that something sucks, lest you not get the message across.  I prefer to
> be blunt.  I got your attention.  The current site, in my opinion, hurts
> QMail more that it helps.  I have offered to help you, and my offer stands.
> It's easy to say something sucks.  It's hard to do something about it.
> Let's do something about it.
> 
> > -Original Message-
> > From: Russell Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 10, 1999 5:31 AM
> > To: QMail List
> > Subject: RE: Patches revisited
> >
> >
> > Lyndon Griffin writes:
> >  > Yeah, I went back, now that you mention it, and I see a lot of
> > work has been
> >  > done since I wrote it off as a dead-loss for information
> > months ago.  No
> >  > offense, Russ, but the presentation of information there is
> > about as good as
> >  > any geoshitties site.  And yes, that can be taken as an offer
> > to help make
> >  > things better, hence the reason for starting this thread.
> >
> > No offense, but your web site sucks?  How *am* I supposed to take that
> > other than as offensive?  I mean, c'mon, really.  If you think it
> > sucks, say so, but don't think you can say it without hurting my
> > feelings.  It's best to strike the phrase "No offense, but" from your
> > vocabulary.
> >
> > I prefer to list everything on one page because it minimizes latency.
> > You download the page once, which doesn't take too awful long because
> > there's almost no graphics.  Then you use your browser's search
> > function to find things that the internal navigation links don't bring
> > you to by browsing.  This, instead of the usual "click, wait.  click,
> > wait" you get from most other web sites.  You can't do much with a
> > small wait, but you can usually find something to do with a big wait
> > to download a big page.
> >
> > So, since you think you can do better, what would you do differently?
> > Split the page up?  That would waste people's time.  Add more
> > information?  I'm fine with that -- "send code", as they say.
> >
> > --
> > -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!
> >

-- 
+ + + + + + + + + + + + + + + + + + + +
Spark Sistemas
   - presentado por IWCC Argentina S.A.
   Tel: 4702-1958
   e-mail: [EMAIL PROTECTED]
+ + + + + + + + + + + + + + + + + + + +