Mailing List Archive: Qmail: users

thoughts on qmail (was: netqmail: reject unknown recipients during SMTP)

1 2

View All

Index | Next | Previous | View Threaded

list-qmail at augensalat

Aug 31, 2009, 5:09 AM

Post #1 of 33 (4368 views)
Permalink

thoughts on qmail (was: netqmail: reject unknown recipients during SMTP)

Gerrit Pape wrote:

> Hi, IIRC there was a plan to include functionality similar to the
> qmail-realrcptto patch from Paul[0] into netqmail, possibly implemented
> in a separate service daemon. Is this still the plan, or even work in
> progress?

It's quite obvious, that there is no progress for qmail at all.
Look at the "official" (net)qmail code.
Look at the "official" qmail website.
It was always the same since Dan released qmail to the public and it
didn't change either after he made all of his work public domain.

Of course there are a lot of patches and everyone uses quite a few of
them to build a custom (ideal?) qmail. A lot of people claim, that this
is the real power of qmail, but actually qmail is passing away silently,
because nobody cares.

This is very sad.

feh at fehcom

Aug 31, 2009, 5:45 AM

Post #2 of 33 (4266 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Hi Bernhard,

On Mon, 31 Aug 2009 14:09:17 +0200, Bernhard Graf
<list-qmail [at] augensalat> wrote:

> It's quite obvious, that there is no progress for qmail at all.
> Look at the "official" (net)qmail code.
> Look at the "official" qmail website.
> It was always the same since Dan released qmail to the public and it
> didn't change either after he made all of his work public domain.
>
> Of course there are a lot of patches and everyone uses quite a few of
> them to build a custom (ideal?) qmail. A lot of people claim, that this
> is the real power of qmail, but actually qmail is passing away silently,
> because nobody cares.

Well. I partially agree with you. Look for instance at the patch Gerrit
requested:

To "reject unknown recipients" there are several solutions available:

- good-rcptto
- valid-rcptto
- Andre Oppermann's integrated LDAP solution ...
- RECIPIENTS extension (my own)
- ....

Probably, all work well, though some are very specific only (valid-rcptto).
However, there is no common understanding within the community, which way
to follow.
Even worse, Russ' qmail site includes some scattered (and often outdated)
references, not sorted by topic.

> This is very sad.

Yes indeed.

regards.
--eh.

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

mhutchinson at manux

Aug 31, 2009, 2:05 PM

Post #3 of 33 (4252 views)
Permalink

RE: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

> > is the real power of qmail, but actually qmail is passing away
> silently,
> > because nobody cares.
>
> Well. I partially agree with you. Look for instance at the patch
Gerrit
> requested:
>
> To "reject unknown recipients" there are several solutions available:
>
> - good-rcptto
> - valid-rcptto
> - Andre Oppermann's integrated LDAP solution ...
> - RECIPIENTS extension (my own)
> - ....

You know, what would be really cool, is if all of the code for Q-Mail
(patches etc) were collaborated into the original source, and these
"patches" became just options or switches to the main program.

That, IMHO, would bring Qmail up-to-date.

Let's be fair, how many people have walked away from using Q-Mail
because of the stigma behind using "patched software" on a mail server?

Our company did.

> Probably, all work well, though some are very specific only (valid-
> rcptto).
> However, there is no common understanding within the community, which
> way
> to follow.
> Even worse, Russ' qmail site includes some scattered (and often
> outdated)
> references, not sorted by topic.

Someone needs to pickup the entrails, create a new website for Q-Mail,
and include some documentation to tie it all together so that
understanding Q-Mail isn't the big mission that it is right now.

Problem is, no-one wants to do this for free, so it probably wont
happen.

Cheers,
Mike

kyle-qmail at memoryhole

Aug 31, 2009, 9:46 PM

Post #4 of 33 (4264 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Monday, August 31 at 02:09 PM, quoth Bernhard Graf:
> Gerrit Pape wrote:
>
>> Hi, IIRC there was a plan to include functionality similar to the
>> qmail-realrcptto patch from Paul[0] into netqmail, possibly implemented
>> in a separate service daemon. Is this still the plan, or even work in
>> progress?
>
> It's quite obvious, that there is no progress for qmail at all.
> Look at the "official" (net)qmail code.
> Look at the "official" qmail website.
> It was always the same since Dan released qmail to the public and it
> didn't change either after he made all of his work public domain.

It seems that you define "progress" by "change". Granted, that is
usually true in most other software. But...

I think the "issue" here, if you can call it that, is that the
qmail.org website and the netqmail code is maintained by people who
*like* qmail the way it is and has always been. People often seem to
forget that qmail 1.03 has existed, unchanged, since 1998. You
remember back when Win98 was the state of the art? Qmail is *OLD*. It
was released into the public domain in 2008. Anyone using qmail or
maintaining qmail in 2008 did so because they liked the state it had
been in for ten years. Should it be really surprising that people who
liked that aren't highly motivated to transform it into something
else, something unlike the thing they grew to love over the previous
ten years, something more akin to all the other software packages out
there?

> Of course there are a lot of patches and everyone uses quite a few of
> them to build a custom (ideal?) qmail. A lot of people claim, that this
> is the real power of qmail, but actually qmail is passing away silently,
> because nobody cares.

I think the continued activity on this list is sufficient evidence to
disprove the idea that "nobody cares".

~Kyle
- --
I'm sick of following my dreams. I'm just going to ask them where
they're going and hook up with them later.
-- Mitch Hedberg
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKnKcWAAoJECuveozR/AWeCM0QAJaiV3oRcDYgUA5q3KDFsnVQ
VTuew5DKbJ1yZu8GKZnCA9vWFb4dU5h1YAS2BTnADPSFrw8AFWgl6RSJnNMz18MA
aiB4h9U5L0uG/3qHaox7XweFCH4m2pKEr4t9ZFuHl3Rz7x6apO+dWyfWGgP1ZJmU
HvxRANYvLZTPBA3fwiL9rIfZeKWp24zlTp20HvXKxRk1+bPDSDLi0/6ZFTPwElYr
YuMj8L3r7oIxcDXTMV/4E5EW3/84R39xQBtjsmsShMX/lw4jqOQ6h9lG1qXVuHmt
P91muq2wYIG5UZ+Rgo46oJKUoAjtjKzXzOBh2HwGV9pXnHKb5HOKJPWmKri83G7N
miBQBBuPdCQZDg4WbiYNXOQBWKPHBJm37KTTPUt6qfV74sbNuDYADGkE69Vz6wM4
OdkA7XsXE1pXvmJsNziY4opT3Q9O5M6Z3wgudIGsNXeHjL2AcruYxzEHAw2Zgy8z
KETtToROJdBJtwHc46Hy5d4G1DGWpYuPmt+zt5gwbPvsoFKs4to2Srf+0ZcGqXdJ
IBkZ/QYGbDj8JbwMyrKMjc/waze4GnkyxpibCZUlxXjhZ4RbG5QQicMQ2WUG1Khj
jlgOA5LkWSVm67+h1vopDrFnQil7Bi+RadMlGtwx1gv5q7khmh2G2xKdxCsi3a6d
wml6VFG/fMrfPCOns4/7
=TR4f
-----END PGP SIGNATURE-----

Jason.Haar at trimble

Aug 31, 2009, 10:00 PM

Post #5 of 33 (4262 views)
Permalink

Re: thoughts on qmail [In reply to]

On 09/01/2009 04:46 PM, Kyle Wheeler wrote:
> People often seem to
> forget that qmail 1.03 has existed, unchanged, since 1998. You
> remember back when Win98 was the state of the art? Qmail is *OLD*. It
> was released into the public domain in 2008. Anyone using qmail or
> maintaining qmail in 2008 did so because they liked the state it had
> been in for ten years.

If anyone wants a more up-to-date version of Qmail, please at least take
a look at the work Mark Johnson is doing with "zinq"

See http://sourceforge.net/projects/zinq/ for details

--
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

feh at fehcom

Sep 1, 2009, 5:24 AM

Post #6 of 33 (4248 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Hi Kyle,

On Tue, 01 Sep 2009 06:46:15 +0200, Kyle Wheeler
<kyle-qmail [at] memoryhole> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Monday, August 31 at 02:09 PM, quoth Bernhard Graf:
>> Gerrit Pape wrote:
>
> It seems that you define "progress" by "change". Granted, that is
> usually true in most other software. But...
>
> I think the "issue" here, if you can call it that, is that the
> qmail.org website and the netqmail code is maintained by people who
> *like* qmail the way it is and has always been. People often seem to
> forget that qmail 1.03 has existed, unchanged, since 1998. You
> remember back when Win98 was the state of the art? Qmail is *OLD*.

Does this matter ? Unix is old. TCP/IP is old. Sockets are an old concept.

The point here is: Qmail, daemontools, djbdns and (most of) the software
DJB has written is done from first principles.
It is almost bug free; however many people missing 'features'.

> It was released into the public domain in 2008. Anyone using qmail or
> maintaining qmail in 2008 did so because they liked the state it had
> been in for ten years. Should it be really surprising that people who
> liked that aren't highly motivated to transform it into something
> else, something unlike the thing they grew to love over the previous
> ten years, something more akin to all the other software packages out
> there?

As with most software: It is is experience to use that matters most;
despite of it's deficiencies and/or shortages.

> I think the continued activity on this list is sufficient evidence to
> disprove the idea that "nobody cares".

Well. I'm not so positive. Remember IM2000. It is dead. Remember ZEROSEEK.
It is dead.

I rather like to have a more substantial discussion about qmail on that
list; other than complaining.

Back to the original topic:

I herewith publish RECIPIENTS extension 0.6 for qmail. I would be pleased
to get some feedback.

http://www.fehcom.de/qmail.html

regards.
--eh.

>
> ~Kyle
> - --
> I'm sick of following my dreams. I'm just going to ask them where
> they're going and hook up with them later.
> -- Mitch Hedberg
> -----BEGIN PGP SIGNATURE-----
> Comment: Thank you for using encryption!
>
> iQIcBAEBCAAGBQJKnKcWAAoJECuveozR/AWeCM0QAJaiV3oRcDYgUA5q3KDFsnVQ
> VTuew5DKbJ1yZu8GKZnCA9vWFb4dU5h1YAS2BTnADPSFrw8AFWgl6RSJnNMz18MA
> aiB4h9U5L0uG/3qHaox7XweFCH4m2pKEr4t9ZFuHl3Rz7x6apO+dWyfWGgP1ZJmU
> HvxRANYvLZTPBA3fwiL9rIfZeKWp24zlTp20HvXKxRk1+bPDSDLi0/6ZFTPwElYr
> YuMj8L3r7oIxcDXTMV/4E5EW3/84R39xQBtjsmsShMX/lw4jqOQ6h9lG1qXVuHmt
> P91muq2wYIG5UZ+Rgo46oJKUoAjtjKzXzOBh2HwGV9pXnHKb5HOKJPWmKri83G7N
> miBQBBuPdCQZDg4WbiYNXOQBWKPHBJm37KTTPUt6qfV74sbNuDYADGkE69Vz6wM4
> OdkA7XsXE1pXvmJsNziY4opT3Q9O5M6Z3wgudIGsNXeHjL2AcruYxzEHAw2Zgy8z
> KETtToROJdBJtwHc46Hy5d4G1DGWpYuPmt+zt5gwbPvsoFKs4to2Srf+0ZcGqXdJ
> IBkZ/QYGbDj8JbwMyrKMjc/waze4GnkyxpibCZUlxXjhZ4RbG5QQicMQ2WUG1Khj
> jlgOA5LkWSVm67+h1vopDrFnQil7Bi+RadMlGtwx1gv5q7khmh2G2xKdxCsi3a6d
> wml6VFG/fMrfPCOns4/7
> =TR4f
> -----END PGP SIGNATURE-----
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

kyle-qmail at memoryhole

Sep 1, 2009, 7:12 AM

Post #7 of 33 (4245 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Dr. Hoffmann,

>> I think the "issue" here, if you can call it that, is that the
>> qmail.org website and the netqmail code is maintained by people who
>> *like* qmail the way it is and has always been. People often seem to
>> forget that qmail 1.03 has existed, unchanged, since 1998. You
>> remember back when Win98 was the state of the art? Qmail is *OLD*.
>
> Does this matter ? Unix is old. TCP/IP is old. Sockets are an old concept.

Well, yes, I think it does. It's not just that Qmail as a concept is
"old"---if that's all I meant, I'd date qmail back to its first
release in 1996. And by that logic, qmail would have to be viewed as
relatively young; sendmail, for example, dates back to at least 1983,
maybe even 1979 (if you count delivermail).

But I'm making reference to the CURRENT qmail in its unaltered
version. THAT's old. That predates Sendmail Inc. That practically
predates spam (1998 is when the New Oxford Dictionary officially added
the definition). The qmail you can download today is bit-for-bit
identical to the qmail you could download back then.

That either means that qmail has completely stagnated (which is what
some people like to claim) OR it means that it has proven itself more
than almost any other software in the history of software (the only
example I can think of that's done better is the stuff that they used
to use on the space shuttle).

Yes, Unix is old... as a concept, and as a concept, I trust it more
than qmail. TCP/IP is old... as a concept, and as a concept, I trust
it more than qmail. Same with sockets. But any given implementation of
Unix? Of TCP/IP? Of sockets? I have to start asking "how many bugs has
it had in the last ten years?" "Has it been *around* for ten years?"
Usually the answers do not compare favorably with qmail. How many
people would be willing to run Linux 2.0.33 (which is what was out
when qmail 1.03 was released) on an internet-connected computer today?

> The point here is: Qmail, daemontools, djbdns and (most of) the
> software DJB has written is done from first principles.
> It is almost bug free; however many people missing 'features'.

I heartily agree.

>> It was released into the public domain in 2008. Anyone using qmail
>> or maintaining qmail in 2008 did so because they liked the state it
>> had been in for ten years. Should it be really surprising that
>> people who liked that aren't highly motivated to transform it into
>> something else, something unlike the thing they grew to love over
>> the previous ten years, something more akin to all the other
>> software packages out there?
>
> As with most software: It is is experience to use that matters most;
> despite of it's deficiencies and/or shortages.

I mostly agree. I think there are some things that are simply bad
choices that cannot be administered well. For example, someone who was
very experienced with Windows 98 and wanted to use that for an
internet-connected file server. No matter how well-administered it is,
I don't trust it.

>> I think the continued activity on this list is sufficient evidence
>> to disprove the idea that "nobody cares".
>
> Well. I'm not so positive. Remember IM2000. It is dead. Remember
> ZEROSEEK. It is dead.

What's that got to do with whether anyone cares about qmail? We've got
*this* list, which has substantive discussions all the time.

> I herewith publish RECIPIENTS extension 0.6 for qmail. I would be
> pleased to get some feedback.
>
> http://www.fehcom.de/qmail.html

Interesting!

Some thoughts:

1. Why do you use str_len(addr.s) in qmail-smtpd.c? addr.len is
probably a better (safer AND faster) option.
2. You probably want to #include auto_break.h in recipients.c,
rather than define AUTO_BREAK yourself.
3. What's the purpose of using a checkpassword compliant API if
you can't really use any of the standard checkpassword programs
(because checking an address is necessarily without a
password)? Unless I'm missing something, this looks similar in
concept to the (older) RCPTCHECK or CHECKENV patches (which I
like, by the way, so I like your patch design for the same
reason), so I'm curious why you chose to go with the
checkpassword design rather than something else (e.g. using the
environment or something like the CVM interface used by
mailfront).
4. It would be neat if your package included example checkpassword
programs that implemented quick equivalents to some of the
other recipient-checking patches, such as realrcptto and
validrcptto (is recipients.cdb equivalent to validrcptto's
cdb?).
5. It might be nice to provide some method of rejecting an email
entirely based on the number of invalid recipients. For
example, a message with ten recipients, but only two valid
ones, is probably not one I really want to accept.

~Kyle
- --
The optimist thinks this is the best of all possible worlds. The
pessimist fears it is true.
-- J. Robert Oppenheimer
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKnSvVAAoJECuveozR/AWexVQQAKfXQ8I4qj3rs8BnjTIvfYvb
5jSc8NYC4o6Z0a1InMP4b9yxVublKjSlHMtW6YEjAYbQWave6Hl7NVLBVVGRIKXs
n37TOf5b6J2s9+LMC1mWXbal21kMwfiNZCVdgevQQSSI3Gfz8zMqi8VCPmzFXu05
QR5Be/nT5XBrLZge6qzPase6Hn7bFPikZhmQ4ysuTR03j1KluXUPEm2a6wYwjxKP
TnA1LcnSk3Sv2X/EG5ZqLsif7RShT+Jxskj4sEk+WGVijNw1Y32V27i5k1pC/m2Q
lEpGh+4Mjigoi7CDGUI/wyM3WqdzBZuzyNl6PMCMdkyxt1nGFUD63zEe2U45nHkD
1sJHHS/8HPjzREg7l19tl13mvK5zMO4uqjOGdda4n1g0rVyTNet4SrNbRXdHbOc+
Twwd5IG44yb7CO3Fg2LQTJd5UuSICgHju009QHwyXIt687dgGsuysdbv+/G28jeq
q0tksEjKts4R6X+8vgUi2dYbzYgIlt0Fd6R33tCCTfGkFfvXrw1ghOLt0ZcLp1i1
B8Aq6/8dHslMWQsoc9ItO1e3y6dXSB7/8ola9crlAeWrXJFjO84VLJsi/1ZcZGHg
h4JwVZvHIaiTpppdCOhlwcDKby8gbRgrI8fP2RCrbSoveikvqa0tTqBaJCfYyvzv
4ay/c24JcE5NbXXdrWD7
=VoXE
-----END PGP SIGNATURE-----

feh at fehcom

Sep 1, 2009, 9:45 AM

Post #8 of 33 (4257 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Hi,

On Tue, 01 Sep 2009 16:12:44 +0200, Kyle Wheeler
<kyle-qmail [at] memoryhole> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Dr. Hoffmann,

keep it less formal. Erwin is enough.

>> Does this matter ? Unix is old. TCP/IP is old. Sockets are an old
>> concept.
>
> Well, yes, I think it does. It's not just that Qmail as a concept is
> "old"---if that's all I meant, I'd date qmail back to its first
> release in 1996. And by that logic, qmail would have to be viewed as
> relatively young; sendmail, for example, dates back to at least 1983,
> maybe even 1979 (if you count delivermail).

I agree. But now you have to consider three circumstances:

- Dan (even pretty young then) did a great design for a MTA.
- Dan circumvented standard lib-C (str*) problems and used is own
uncompromised coding.
- Dan managed to realise a code ('10 years of qmail') with very, very few
bugs and flaws only.

> But I'm making reference to the CURRENT qmail in its unaltered
> version. THAT's old. That predates Sendmail Inc. That practically
> predates spam (1998 is when the New Oxford Dictionary officially added
> the definition). The qmail you can download today is bit-for-bit
> identical to the qmail you could download back then.

Yes, I agree entirely.

> That either means that qmail has completely stagnated (which is what
> some people like to claim) OR it means that it has proven itself more
> than almost any other software in the history of software (the only
> example I can think of that's done better is the stuff that they used
> to use on the space shuttle).

Well. We call that 'high-integrity' software (design).

> Yes, Unix is old... as a concept, and as a concept, I trust it more
> than qmail. TCP/IP is old... as a concept, and as a concept, I trust
> it more than qmail. Same with sockets. But any given implementation of
> Unix? Of TCP/IP? Of sockets? I have to start asking "how many bugs has
> it had in the last ten years?" "Has it been *around* for ten years?"
> Usually the answers do not compare favorably with qmail. How many
> people would be willing to run Linux 2.0.33 (which is what was out
> when qmail 1.03 was released) on an internet-connected computer today?

Since an OS is always hardware dependent, I would not try to compare those.
But, in comparision: I would not hestitate, to take FreeBSD 3.51 out of my
drawer and install that together with qmail+tcpserver+djbdns and use it as
an Internet server for mail (I commit: The load of the server should be <
1 mio mails/day).
Did you read about Apache's stolen SSH-key recently ? Most of the security
problems today originate *not* from software deficiencies rather from
unconcious (ab)use.

>> As with most software: It is is experience to use that matters most;
>> despite of it's deficiencies and/or shortages.
>
> I mostly agree. I think there are some things that are simply bad
> choices that cannot be administered well. For example, someone who was
> very experienced with Windows 98 and wanted to use that for an
> internet-connected file server. No matter how well-administered it is,
> I don't trust it.
>
>>> I think the continued activity on this list is sufficient evidence
>>> to disprove the idea that "nobody cares".
>>
>> Well. I'm not so positive. Remember IM2000. It is dead. Remember
>> ZEROSEEK. It is dead.
>
> What's that got to do with whether anyone cares about qmail? We've got
> *this* list, which has substantive discussions all the time.

No one picked that up. Regarding the basic design of qmail, two problems
come to my mind:

1: qmail is heavily I/O bound. Regarding current situations this is still
a bottleneck.
This might change, if we run on solid-sate disks; but thats the future.
To recall: Two solutions have been made available to overcome this:
Andre Opperman's EXT-BIG-TODO and my Qmail Multiple Queue QMQ design.
2. qmail's atomic delivery scheme (to the same domain) is not very welcome
anymore and puts an additional burden on the recipient system.

(1.) can be relaxed with ZEROSEEK. But I hardly find any additional ideas.
(2.) has not even touched yet.

>> I herewith publish RECIPIENTS extension 0.6 for qmail. I would be
>> pleased to get some feedback.
>>
>> http://www.fehcom.de/qmail.html
>
> Interesting!
>
> Some thoughts:
>
> 1. Why do you use str_len(addr.s) in qmail-smtpd.c? addr.len is
> probably a better (safer AND faster) option.

Sure. Could do so; but it hardly makes any difference.

> 2. You probably want to #include auto_break.h in recipients.c,
> rather than define AUTO_BREAK yourself.

Ok. Good idea.

> 3. What's the purpose of using a checkpassword compliant API if
> you can't really use any of the standard checkpassword programs
> (because checking an address is necessarily without a
> password)? Unless I'm missing something, this looks similar in
> concept to the (older) RCPTCHECK or CHECKENV patches (which I
> like, by the way, so I like your patch design for the same
> reason), so I'm curious why you chose to go with the
> checkpassword design rather than something else (e.g. using the
> environment or something like the CVM interface used by
> mailfront).

Im not familiar with RCPTCHECK, CHECKENV, and mailfront. I have to
apologize.
The Recipients extension is already pretty old and originally designed to
use a cdb.

I've picked up the idea of environment variables in SPAMCONTROL 2.5.
However, the development for the Recipients extension -- and particular --
the use of LDAP was one of the design ideas.

If you look at the UNIX login, the baisc idea is the 'PAM'.
Dan invented the checkpassword API. Why not keep a useful infrastructure
and invent something new ?
The checkpassword API is generic; if you use environment variables you
have to know them by name.

> 4. It would be neat if your package included example checkpassword
> programs that implemented quick equivalents to some of the
> other recipient-checking patches, such as realrcptto and
> validrcptto (is recipients.cdb equivalent to validrcptto's
> cdb?).

I does partially. The ldapam.pl is *excatly* suited for this.

However, the RECIPIENTS extension is a more general approach.
I tried to explain the problem with the different user databases on my web
page.
vpopmail is one implementation, Bruce Guenther's vmailmgr is another
option.

Actually, there exist already at least one solution for vpopmail +
Recipients API.
I will reference that on my web page soon (in case I'm permitted).

> 5. It might be nice to provide some method of rejecting an email
> entirely based on the number of invalid recipients. For
> example, a message with ten recipients, but only two valid
> ones, is probably not one I really want to accept.

You can have that feature in SPAMCONTROL (which includes the RECIPIENTS
extension).

Thank you for your remarks and the lively discussion.
--eh.

>
> ~Kyle
> - --
> The optimist thinks this is the best of all possible worlds. The
> pessimist fears it is true.
> -- J. Robert Oppenheimer
> -----BEGIN PGP SIGNATURE-----
> Comment: Thank you for using encryption!
>
> iQIcBAEBCAAGBQJKnSvVAAoJECuveozR/AWexVQQAKfXQ8I4qj3rs8BnjTIvfYvb
> 5jSc8NYC4o6Z0a1InMP4b9yxVublKjSlHMtW6YEjAYbQWave6Hl7NVLBVVGRIKXs
> n37TOf5b6J2s9+LMC1mWXbal21kMwfiNZCVdgevQQSSI3Gfz8zMqi8VCPmzFXu05
> QR5Be/nT5XBrLZge6qzPase6Hn7bFPikZhmQ4ysuTR03j1KluXUPEm2a6wYwjxKP
> TnA1LcnSk3Sv2X/EG5ZqLsif7RShT+Jxskj4sEk+WGVijNw1Y32V27i5k1pC/m2Q
> lEpGh+4Mjigoi7CDGUI/wyM3WqdzBZuzyNl6PMCMdkyxt1nGFUD63zEe2U45nHkD
> 1sJHHS/8HPjzREg7l19tl13mvK5zMO4uqjOGdda4n1g0rVyTNet4SrNbRXdHbOc+
> Twwd5IG44yb7CO3Fg2LQTJd5UuSICgHju009QHwyXIt687dgGsuysdbv+/G28jeq
> q0tksEjKts4R6X+8vgUi2dYbzYgIlt0Fd6R33tCCTfGkFfvXrw1ghOLt0ZcLp1i1
> B8Aq6/8dHslMWQsoc9ItO1e3y6dXSB7/8ola9crlAeWrXJFjO84VLJsi/1ZcZGHg
> h4JwVZvHIaiTpppdCOhlwcDKby8gbRgrI8fP2RCrbSoveikvqa0tTqBaJCfYyvzv
> 4ay/c24JcE5NbXXdrWD7
> =VoXE
> -----END PGP SIGNATURE-----
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

johnsonm at gmail

Sep 2, 2009, 11:08 AM

Post #9 of 33 (4230 views)
Permalink

Re: thoughts on qmail [In reply to]

On Tue, Sep 1, 2009 at 12:00 AM, Jason Haar<Jason.Haar [at] trimble> wrote:
> On 09/01/2009 04:46 PM, Kyle Wheeler wrote:
>> People often seem to
>> forget that qmail 1.03 has existed, unchanged, since 1998. You
>> remember back when Win98 was the state of the art? Qmail is *OLD*. It
>> was released into the public domain in 2008. Anyone using qmail or
>> maintaining qmail in 2008 did so because they liked the state it had
>> been in for ten years.
>
> If anyone wants a more up-to-date version of Qmail, please at least take
> a look at the work Mark Johnson is doing with "zinq"
>
> See http://sourceforge.net/projects/zinq/ for details

Progress on my qmail fork has been stalled for a while now as I've
been busy forking ucspi-tcp, daemontools and djbdns, too. Presently
I'm in the middle of converting the build process to autoconf/automake
and ripping out the hardcoded UIDs.

Feel free to contribute. Or create your own fork. The djb-derived
code in zinq is public domain, if you see anything you like, help
yourself.

lists-qmail at maexotic

Sep 2, 2009, 6:51 PM

Post #10 of 33 (4222 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

On Tue, Sep 01, 2009 at 09:12:44AM -0500, Kyle Wheeler wrote:
> That either means that qmail has completely stagnated (which is what
> some people like to claim) OR it means that it has proven itself more
> than almost any other software in the history of software (the only
> example I can think of that's done better is the stuff that they used
> to use on the space shuttle).

I know some people will hate me ...
I am using qmail sind 1.01 and I have used 1.03 on some hundreds of
server with probably some millions of users.
I have kinda forked my own version of qmail around 2000 and deployed
that with an ISP I was working for. Over the years those fork has
changed massively with patches from the community and countless of my
own.

Even with my own small little mailserver with two domains a vanilla
qmail (or even netqmail) is totally unoperable these days. This is my
strong believe. There are a lot of small things to nitpick about, but
these are (for me) the 4 killers:
- no recipient checks.
accepting all emails prior to existency checking and then sending out
bounces is totally unacceptable these days.
Yes, there are patches.
How error prone is it to manage a qmail server with these patches?
How many files do I have to edit to add a new user? How much work is to
be done besides clicking through some web interface? (sorry, I have
stopped following v*something a few years back, after I have evaluated
it and found it totally not suitable for hosting mailservers and virtual
domains wrt to security and usability).
- no SMTP AUTH/SUBMISSION support
I am reading mails on my server via mutt. I wanted to set up qmail so
my Mom (virtual email account) can read/send via that server with IMAP.
Can you spell "pain in the ass"? I had working SMTP AUTH in the
server, but I don't want a real user. I don't want (IMHO clumsy)
v* management tools and I surely don't want LDAP (an option I have tried,
but gave up as I only found f*cked up ldapcheckpasswd "scripts").
I want only one fucking user (let them be 20 for a small company) and
I want it quick and easy and I don't want some 100 additional software
packages just for that.
I ended up writing my own checkpassword that checks a user:pass file
(containing one line).
Luckily the IMAP daemon I chose was able to work with that, too.
- forget about POP3 these days
but have you tried *cleanly* (yes, cleanly, not just somehow) integrating
qmail in a "modern" IMAP server? Nothing I'd wish anybody to be their job.
Oh and you can find tons of documentation how to do this ... for postfix.
- spam/viruses/DKIM
yes ... hundreds of patches. Most of them you can probably find on
qmail.org. Then you have some days of fun playing the "which one to
use" and the "which patch in which order" and then the "oh noooos ...
handediting time" game.
And yes, if you are lucky you may even find some documentation, but
probably not and for sure not in one place.

Yes, I really like qmail. There is probably not one line of source code I
haven't looked at at least 10 times, so I am pretty familiar with it. I will
use it for my private server as long as possible.

But I wouldn't use qmail now, if I'd to start fresh as I did 1998, and I've
stopped using qmail for customers that want to manage the mailserver their
own, after some time. I just think that wouldn't be fair (think updates,
documentation, manageability).

\Maex

--
Markus Stumpf

amb-1249960183 at bradfords

Sep 2, 2009, 8:16 PM

Post #11 of 33 (4226 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Thus said Kyle Wheeler on Mon, 31 Aug 2009 23:46:15 CDT:

> People often seem to forget that qmail 1.03 has existed, unchanged,
> since 1998. You remember back when Win98 was the state of the art?
> Qmail is *OLD*.

And yet... how many people are still running Win98? Of those who might
be, how many dare to hook it up to the Internet? Good design can take
software a long way.

Andy
--
[-----------[system uptime]--------------------------------------------]
9:16pm up 11 min, 1 user, load average: 1.32, 1.34, 0.80

amb-1249960183 at bradfords

Sep 2, 2009, 8:18 PM

Post #12 of 33 (4232 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Thus said "Erwin Hoffmann" on Tue, 01 Sep 2009 14:24:22 +0200:

> Well. I'm not so positive. Remember IM2000. It is dead. Remember
> ZEROSEEK. It is dead.

Is zeroseek really dead? That would be unfortunate, seemed like a good
idea. I know that IM2000 hasn't had much progress.

Andy
--
[-----------[system uptime]--------------------------------------------]
9:18pm up 13 min, 1 user, load average: 1.06, 1.24, 0.82

kyle-qmail at memoryhole

Sep 2, 2009, 10:49 PM

Post #13 of 33 (4221 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thursday, September 3 at 03:51 AM, quoth Markus Stumpf:
> On Tue, Sep 01, 2009 at 09:12:44AM -0500, Kyle Wheeler wrote:
>> That either means that qmail has completely stagnated (which is what
>> some people like to claim) OR it means that it has proven itself more
>> than almost any other software in the history of software (the only
>> example I can think of that's done better is the stuff that they used
>> to use on the space shuttle).
>
> I know some people will hate me ...

Hate's a pretty strong thing. :(

> Even with my own small little mailserver with two domains a vanilla
> qmail (or even netqmail) is totally unoperable these days. This is
> my strong believe.

I don't know about inoperable. Dictionary definition of the word
doesn't fit.

In any case, I'll agree, qmail is certainly not at all the solution
for someone who wants a drop-in turn-key full-featured solution. Qmail
is, imho, an *architecture* more than a specific mail implementation.
(Consider, for example, qmail+mailfront.) I see it as the basis upon
which one can build a slim, trim, no-bloat system. It's a framework
upon which to hang exactly the components you need and none of the
ones you don't.

It all depends on how you look at it, and what you're expecting.
Similarly, UNIX isn't, in and of itself, great for *any* specific
purpose. But given the right tools, you can build some pretty slick
stuff out of a UNIX framework.

~Kyle
- --
They say marriages are made in Heaven. But so is thunder and
lightning.
-- Clint Eastwood
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKn1jTAAoJECuveozR/AWenjoQAKN0o08Jhudw2ryDSLsX3K+2
FpRexTnSL2Tr74e1CnoQjxSBV4Xu8MjD/BFqoCzfYZ3mKdOnMYKxJbXr8PnDomDo
qtfmIuEange37iOYzO+K9X4W41SJdLC+UpOO1tyMUZiTGa1dVMuIl5PuwuyshRDd
hDocbc/DL29mxP3To19rQz8Yr21rUVQ1cwZvr1C5dZtF3ZXXnhYalZTCJKkgd980
jrCrofDsMX9UU/Oxs/UQleiSFI0gZ7yDf+nr/GPJh41/FK7SJcBh/pzXhf+UoKAj
MPMvG/pkUDoQj1P07viYUNvu74hf8DMvudDWXW77xZ7pDOlFDxpCjMBco2oNBCdZ
51VruzM9qZdydEUAXNT4S1ex9GHrXHyHxeIzWtDV3UT73GwlxEmUChn4I1mlJc3S
oAqXtfAPw/CMYbgLnj52WnydSAGz1V1UYPLvmtZCbu/hBERtdRh4Ltf2O71K1uOc
BFDpqFpcbhqBsHBeK3HxZ6uS4km8KQyhTVRgktIRu426OnTe3h6B/+/e1gA4BRu2
q6IH8V9okEk00ZioSQU0gGKg9t5ix//OB9hzxemqS0ebl3EiH3Tj20U3jgr3i9mQ
QeAOiRCG16xYYDW1cO2Msfr8wesdxT0i5BW0sqOug+DGsvMTZtBv3daOZvYxTPUK
ph0v4kdrNPtICc2ydtuF
=ivhM
-----END PGP SIGNATURE-----

feh at fehcom

Sep 3, 2009, 1:30 AM

Post #14 of 33 (4229 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Hi Markus,

On Thu, 03 Sep 2009 03:51:28 +0200, Markus Stumpf
<lists-qmail [at] maexotic> wrote:

> On Tue, Sep 01, 2009 at 09:12:44AM -0500, Kyle Wheeler wrote:
>> That either means that qmail has completely stagnated (which is what
>> some people like to claim) OR it means that it has proven itself more
>> than almost any other software in the history of software (the only
>> example I can think of that's done better is the stuff that they used
>> to use on the space shuttle).
>
> I know some people will hate me ...

Certainly not.

> I am using qmail sind 1.01 and I have used 1.03 on some hundreds of
> server with probably some millions of users.
> I have kinda forked my own version of qmail around 2000 and deployed
> that with an ISP I was working for. Over the years those fork has
> changed massively with patches from the community and countless of my
> own.

Me too.

> Even with my own small little mailserver with two domains a vanilla
> qmail (or even netqmail) is totally unoperable these days. This is my
> strong believe. There are a lot of small things to nitpick about, but
> these are (for me) the 4 killers:
> - no recipient checks.
> accepting all emails prior to existency checking and then sending out
> bounces is totally unacceptable these days.
> Yes, there are patches.

Probably you know my own (RECIPIENTS extension).
This almost the cleanest, eaysiest, and general purpuse API/implementation
*I* can think of.
(maybe I'm mistaken).

> - no SMTP AUTH/SUBMISSION support

We've discussed that issue.
It is included in my SMTP-Auth patch; though this is far from 'perfect' or
well designed.

> but have you tried *cleanly* (yes, cleanly, not just somehow)
> integrating
> qmail in a "modern" IMAP server? Nothing I'd wish anybody to be their
> job.

Actually, I was planning to look into that more deeply.
Apart for user authentication, one really striking problem is the Maildir
support.

Maildir++ as defined, is a piece of shit from my understanding.
Having the tmp/new/cur logic at every level is ugly.
Concatinging Maildirs in a single path in the way binc is doing (with the
leading .) is unacceptable.
It will eventually break the possible path length.

What about the interoperability between mutt, binc, and dovecot ?

> - spam/viruses/DKIM
> yes ... hundreds of patches. Most of them you can probably find on
> qmail.org. Then you have some days of fun playing the "which one to
> use" and the "which patch in which order" and then the "oh noooos ...
> handediting time" game.
> And yes, if you are lucky you may even find some documentation, but
> probably not and for sure not in one place.

Some of those originate from me.
DKIM is stil unsolved (from my perspektive).

> Yes, I really like qmail. There is probably not one line of source code I
> haven't looked at at least 10 times, so I am pretty familiar with it. I
> will
> use it for my private server as long as possible.
>
> But I wouldn't use qmail now, if I'd to start fresh as I did 1998, and
> I've
> stopped using qmail for customers that want to manage the mailserver
> their
> own, after some time. I just think that wouldn't be fair (think updates,
> documentation, manageability).

Yes and thats *particular* the reasons why even my customers use postfix
instead of qmail these days (or have outsourced their email).

I don't blame Dan for that; but the patch + 'code management' problem is
certainly due to rank growth of patches available on qmail.org.

Just to tell a funny story about a similiar topic in Germany:

Here, we have a (almost) company doing tests on in particluar electronic
customer goods (TV sets, cameras, washing machines ....).
Years ago, a washing machine from a particular brand was labeled 'very
good', 'energy efficient', and 'priceworthy'-
Those results were/are published in a monthly newsletter magazine.

Mums copied that report and gave that to their daughters and told them:
Buy that washing machine, it is good (ok. it was not as simple as that).
10 and even 20 years later, the technology of the washing machine was
certainly superseeded; none of the quality characeristics could sustain,
of course.
However, due to that circulating report the vendor was forced to produce
that machine even after it's natural life time did exceed.

Back to qmail: With many outdated patches on qmail.org, it is about the
same (see the reference to the qmail-remote-auth patch recently).
Further: Based on half-baked patches, people build up, new, even more
complex settings, requiring even additional sources (SASL, OpenSSL, v*).

If qmail is going to survice the *next* ten years, we really need to clean
up that mess.

Follow that thread (in German):

http://www.heise.de/netze/news/foren/S-Mac-OS-X-Server-ist-fast-noch-besser-als-die-Client-Variante/forum-164825/msg-17284744/read/

regards.
--eh.

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

kyle-qmail at memoryhole

Sep 3, 2009, 8:35 AM

Post #15 of 33 (4195 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thursday, September 3 at 10:30 AM, quoth Erwin Hoffmann:
>> but have you tried *cleanly* (yes, cleanly, not just somehow)
>> integrating qmail in a "modern" IMAP server? Nothing I'd wish
>> anybody to be their job.
>
> Actually, I was planning to look into that more deeply.
> Apart for user authentication, one really striking problem is the
> Maildir support.
>
> Maildir++ as defined, is a piece of shit from my understanding.
> Having the tmp/new/cur logic at every level is ugly.
> Concatinging Maildirs in a single path in the way binc is doing (with
> the leading .) is unacceptable.
> It will eventually break the possible path length.
>
> What about the interoperability between mutt, binc, and dovecot ?

Actually, I haven't had any problems integrating qmail and dovecot (I
use mutt all the time). They even have an FS Maildir layout, which
fixes the path length problem you mentioned. Dovecot supports
checkpasswd natively... it's really quite nice.

> Some of those originate from me. DKIM is stil unsolved (from my
> perspektive).

Really? I have a set of wrapper scripts that produce DKIM signatures
on outbound email. What problems/features remain unresolved? I'd be
happy to look into them (unless you're just objecting to using Perl
and/or wrapper scripts).

~Kyle
- --
A fanatic is one who can't change his mind and won't change the
subject.
-- Winston Churchill, July 5, 1954
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKn+JBAAoJECuveozR/AWezyoQAIRgjghMVL+MB/ntbytDh2Wm
AFk5CVwS2nu2s9DkK25cZLIfUQyvNhGtSYDVlCxXbjso3kiPq6SujmyCpEgeN3ta
NaTA1riwDZ7cNmOTDM3f9J++u4I4WTP8ZuSdyngjce8mPhg/vpZP5Gserhl+D9+L
JQErTkFgRudLZTz/Ffo+/7oodmVtg9vlnNRJTmfcj6KDz9nMJiuWAqJm1gysD0vo
f6M6kdcRPX9E5j3vaDEaK0i1z+PJDO1lkAWc0B0Gl05EMJghX/jOAUDo8i7ViWh0
RMNAL7UbUFBRpc7ciZn/CnFznf8+MXicZgmBLntplcVkp5NevXA1LPPE5rv9Rn7z
tath2bO/5fnGos1PlhBRIy7FaOSPyb3ArICraFRMZjPg0Nf2BBX5F0At5QYRIlqH
PMq/Dm0AFx2aKbhSYAJkIM4KaeZFjQUNdvjnwaF16sbaHK2SoVRa8Q2ujj+QZWMP
c3VGQHy/Uli9wjs6nyXKEs5O/jBccTybdQBiOiN4pFPIO2lQI3VuCrA7wVuD+m7C
/HKk/GD+n+++3mhyt21q9mDgqnhfkLPe3xT/yEHbsgPr2QJBdPnQ/KLPPSWQ1cqH
qIG9t4QAWu5+AOiJINGrlGAQfcFFPWVSRYf28tIOMqsG0XePfVkl5BDQZqa7Sypy
arwVVWKjSUyEnkxf3tia
=s4tE
-----END PGP SIGNATURE-----

feh at fehcom

Sep 3, 2009, 8:59 AM

Post #16 of 33 (4202 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Hi Kyle,

On Thu, 03 Sep 2009 17:35:30 +0200, Kyle Wheeler
<kyle-qmail [at] memoryhole> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>>
>> What about the interoperability between mutt, binc, and dovecot ?
>
> Actually, I haven't had any problems integrating qmail and dovecot (I
> use mutt all the time). They even have an FS Maildir layout, which
> fixes the path length problem you mentioned. Dovecot supports
> checkpasswd natively... it's really quite nice.

Well. Good point to change to Dovecot.

>
>> Some of those originate from me. DKIM is stil unsolved (from my
>> perspektive).
>
> Really? I have a set of wrapper scripts that produce DKIM signatures
> on outbound email. What problems/features remain unresolved? I'd be
> happy to look into them (unless you're just objecting to using Perl
> and/or wrapper scripts).

I did not look into your solutions yet. Sorry.

But you know: One needs to tackle DKIM on three sides:

Providing the records in DNS (outside qmail).
Inserting the Header lines (as you mentioned).
Reading and perhaps acting on the (missing) DKIM signature at smtp-level.

Now to the problem:

qmail(-smtpd) acts well as server for different (virtual domains).
qmail(-remote) has currently no understanding regarding the reverse path.

Think about: Bounces, IP binding, outbound Authentication, Certificates,
DKIM Signatures.

In Spamcontrol 2.5, I provided a solution for Bounces.
In Spamcontrol 2.6, I will outline a solution of IP binding and
Certificates.

Therefore I said: "DKIM is still unsolved (from my perspective)"

regards.
--eh.

>
> ~Kyle
> - --
> A fanatic is one who can't change his mind and won't change the
> subject.
> -- Winston Churchill, July 5, 1954
> -----BEGIN PGP SIGNATURE-----
> Comment: Thank you for using encryption!
>
> iQIcBAEBCAAGBQJKn+JBAAoJECuveozR/AWezyoQAIRgjghMVL+MB/ntbytDh2Wm
> AFk5CVwS2nu2s9DkK25cZLIfUQyvNhGtSYDVlCxXbjso3kiPq6SujmyCpEgeN3ta
> NaTA1riwDZ7cNmOTDM3f9J++u4I4WTP8ZuSdyngjce8mPhg/vpZP5Gserhl+D9+L
> JQErTkFgRudLZTz/Ffo+/7oodmVtg9vlnNRJTmfcj6KDz9nMJiuWAqJm1gysD0vo
> f6M6kdcRPX9E5j3vaDEaK0i1z+PJDO1lkAWc0B0Gl05EMJghX/jOAUDo8i7ViWh0
> RMNAL7UbUFBRpc7ciZn/CnFznf8+MXicZgmBLntplcVkp5NevXA1LPPE5rv9Rn7z
> tath2bO/5fnGos1PlhBRIy7FaOSPyb3ArICraFRMZjPg0Nf2BBX5F0At5QYRIlqH
> PMq/Dm0AFx2aKbhSYAJkIM4KaeZFjQUNdvjnwaF16sbaHK2SoVRa8Q2ujj+QZWMP
> c3VGQHy/Uli9wjs6nyXKEs5O/jBccTybdQBiOiN4pFPIO2lQI3VuCrA7wVuD+m7C
> /HKk/GD+n+++3mhyt21q9mDgqnhfkLPe3xT/yEHbsgPr2QJBdPnQ/KLPPSWQ1cqH
> qIG9t4QAWu5+AOiJINGrlGAQfcFFPWVSRYf28tIOMqsG0XePfVkl5BDQZqa7Sypy
> arwVVWKjSUyEnkxf3tia
> =s4tE
> -----END PGP SIGNATURE-----
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de

mbhangui at gmail

Sep 3, 2009, 9:57 AM

Post #17 of 33 (4215 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

On Thu, Sep 3, 2009 at 9:29 PM, Erwin Hoffmann<feh [at] fehcom> wrote:
> But you know: One needs to tackle DKIM on three sides:
>
> Providing the records in DNS (outside qmail).
> Inserting the Header lines (as you mentioned).
> Reading and perhaps acting on the (missing) DKIM signature at smtp-level.
>
> Now to the problem:
>
> qmail(-smtpd) acts well as server for different (virtual domains).
> qmail(-remote) has currently no understanding regarding the reverse path.
>
I am not sure if I have understood it right. But If you are looking at
different behaviour of qmail-smtpd, qmail-remote for each domain. e.g.
setting QMAILQUEUE=/var/qmail/bin/qmail-dkim for DKIM signing for just
few specific virtual domains and not for others, you can do that by
using my envrules() function inside qmail-smtpd.c, qmail-rspawn.c and
qmail-lspawn.c. The envrules() hack allows qmail to behave differently
for each domain (the domain in the return-path in qmail-smtpd and the
domain in the recipient for qmail-local and qmail-remote)

Also I have qmail-dkim (drop-in replacement for qmail-queue) with ADSP
which can do DKIM verification for specific domains based on the
Signing Practice of the domain. All my code is under GPL at
http://indimail.sourceforge.net. I can provide more info if needed.

Regards Manvendra

nelson at crynwr

Sep 3, 2009, 10:46 PM

Post #18 of 33 (4181 views)
Permalink

Re: thoughts on qmail (was: netqmail: reject unknown recipients during SMTP) [In reply to]

Erwin Hoffmann writes:
> Even worse, Russ' qmail site includes some scattered (and often outdated)
> references, not sorted by topic.

Not sorted by topic? Well, it *is* sorted by topic, so obviously you
must be talking about something else. Care to explain?

--
--my blog is at http://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-323-1241
Potsdam, NY 13676-3213 | Sheepdog

nelson at crynwr

Sep 3, 2009, 10:48 PM

Post #19 of 33 (4181 views)
Permalink

Re: thoughts on qmail [In reply to]

Mark Johnson writes:
> Presently I'm in the middle of converting the build process to
> autoconf/automake

I still don't understand what problem that solves (unless you define
the problem as "qmail doesn't use autoconf", in which case I define
the problem "qmail doesn't give you a pony" and encourage solutions.)

--
--my blog is at http://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-323-1241
Potsdam, NY 13676-3213 | Sheepdog

search-web-for-address at pyropus

Sep 4, 2009, 7:22 AM

Post #20 of 33 (4169 views)
Permalink

Re: thoughts on qmail [In reply to]

Russell Nelson <nelson [at] crynwr> wrote:
> Mark Johnson writes:
> > Presently I'm in the middle of converting the build process to
> > autoconf/automake
>
> I still don't understand what problem that solves (unless you define
> the problem as "qmail doesn't use autoconf", in which case I define
> the problem "qmail doesn't give you a pony" and encourage solutions.)

Indeed, I'm the same way. When I wanted to make another project of mine more
portable, I spent a while trying to use autoconf/automake before giving up and
switching to djb's way -- it was far easier, and more importantly, the code is
far more readable, so bugs are less likely to slip through.

I think autoconf/automake are signs of a GNU fetish :).

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

johnsonm at gmail

Sep 4, 2009, 11:24 AM

Post #21 of 33 (4162 views)
Permalink

Re: thoughts on qmail [In reply to]

On Fri, Sep 4, 2009 at 9:22 AM, Charles
Cazabon<search-web-for-address [at] pyropus> wrote:
> Russell Nelson <nelson [at] crynwr> wrote:
>> I still don't understand what problem that solves (unless you define
>> the problem as "qmail doesn't use autoconf", in which case I define
>> the problem "qmail doesn't give you a pony" and encourage solutions.)
>
> Indeed, I'm the same way. �When I wanted to make another project of mine more
> portable, I spent a while trying to use autoconf/automake before giving up and
> switching to djb's way -- it was far easier, and more importantly, the code is
> far more readable, so bugs are less likely to slip through.
>
> I think autoconf/automake are signs of a GNU fetish :).
>
> Charles

So you've got a copy of redo? If not, I don't think you've switched
to "djb's way".

johnsonm at gmail

Sep 4, 2009, 11:28 AM

Post #22 of 33 (4154 views)
Permalink

Re: thoughts on qmail [In reply to]

On Fri, Sep 4, 2009 at 12:48 AM, Russ Nelson<nelson [at] crynwr> wrote:
> Mark Johnson writes:
> �> Presently I'm in the middle of converting the build process to
> �> autoconf/automake
>
> I still don't understand what problem that solves (unless you define
> the problem as "qmail doesn't use autoconf", in which case I define
> the problem "qmail doesn't give you a pony" and encourage solutions.)

Quit trying to pick a fight and go release some software. Or convince
Dan to publish redo:

http://cr.yp.to/redo.html

search-web-for-address at pyropus

Sep 4, 2009, 12:20 PM

Post #23 of 33 (4147 views)
Permalink

Re: thoughts on qmail [In reply to]

Mark Johnson <johnsonm [at] gmail> wrote:
> >
> > I think autoconf/automake are signs of a GNU fetish :).
>
> So you've got a copy of redo? If not, I don't think you've switched
> to "djb's way".

I have switched memtester to djb's way, and no I don't have redo. All the
necessary bits you need are included with the qmail or djbdns packages -- they
are, after all, how that software is built portably.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon
GPL'ed software available at: http://pyropus.ca/software/
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
--------------------------------------------------------------------------

johnsonm at gmail

Sep 4, 2009, 12:50 PM

Post #24 of 33 (4140 views)
Permalink

Re: thoughts on qmail [In reply to]

On Fri, Sep 4, 2009 at 2:20 PM, Charles
Cazabon<search-web-for-address [at] pyropus> wrote:
> I have switched memtester to djb's way, and no I don't have redo. �All the
> necessary bits you need are included with the qmail or djbdns packages -- they
> are, after all, how that software is built portably.
>
> Charles

All the necessary bits are *not* included with qmail or djbdns.
Specifically, whatever tool generated the Makefiles. I've been told
that's redo. You may be happy doing by hand what djb did with a tool,
good for you. But you're not doing it "djb's way", not entirely.
Without the unpublished bits of his build system, I prefer to use
another entirely. Please understand this choice and accept it,
instead of trying to start another 'autoconf sucks' thread.

bh at izb

Sep 4, 2009, 2:50 PM

Post #25 of 33 (4136 views)
Permalink

Re: thoughts on qmail [In reply to]

At 4 Sep 2009 08:22:05 -0600,
Charles Cazabon wrote:
>
> Russell Nelson <nelson [at] crynwr> wrote:
> > Mark Johnson writes:
> > > Presently I'm in the middle of converting the build process to
> > > autoconf/automake
> >
> > I still don't understand what problem that solves (unless you define
> > the problem as "qmail doesn't use autoconf", in which case I define
> > the problem "qmail doesn't give you a pony" and encourage solutions.)
>
> [...]
> I think autoconf/automake are signs of a GNU fetish :).
>

Do not insult GNU by using the word "fetish". GNU gave Professor
Bernstein good infrastructure of thought. GNU is his Godfather.

--
Byung-Hee HWANG
∑ WWW: http://izb.knu.ac.kr/~bh/

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads