Mailing List Archive

Unable to run qmail-remote
Thanks for helping me with unable to chdir to maildir;
actually, it was an error in my assign file.
Now, I've got another one: unable to run qmail-remote.
I have checked the mailing list archive and here are
the solutions I tried:

- run make setup check
- check the permissions on /var/qmail/bin
- check that qmail is run with /var/qmail/bin in the
path (it is and I'm sure of it since local mail works)
- repair the queue with queue-fix

Here is the result of ls -l in /var/qmail/bin:

total 692
lrwxrwxrwx 1 root root 8 Feb 23
15:23 bin -> /usr/bin
-rwxr-xr-x 1 root qmail 9260 Mar 17
13:46 bouncesaying
-rwxr-xr-x 1 root qmail 15512 Mar 17
13:46 condredirect
-rwxr-xr-x 1 root qmail 126 Mar 17
13:46 datemail
-rwxr-xr-x 1 root qmail 114 Mar 17
13:46 elq
-rwxr-xr-x 1 root qmail 9196 Mar 17
13:46 except
-rwxr-xr-x 1 root qmail 14480 Mar 17
13:46 forward
-rwxr-xr-x 1 root qmail 19144 Mar 17
13:46 maildir2mbox
-rwxr-xr-x 1 root qmail 8904 Mar 17
13:46 maildirmake
-rwxr-xr-x 1 root qmail 17400 Mar 17
13:46 maildirwatch
-rwxr-xr-x 1 root qmail 179 Mar 17
13:46 mailsubj
-rwxr-xr-x 1 root qmail 115 Mar 17
13:46 pinq
-rwxr-xr-x 1 root qmail 13012 Mar 17
13:46 predate
-rwxr-xr-x 1 root qmail 13228 Mar 17
13:46 preline
-rwxr-xr-x 1 root qmail 115 Mar 17
13:46 qail
-rwxr-xr-x 1 root qmail 11948 Mar 17
13:46 qbiff
-rwx--x--x 1 root qmail 10280 Mar 17
13:46 qmail-clean
-rwx--x--x 1 root qmail 5868 Mar 17
13:46 qmail-getpw
-rwxr-xr-x 1 root qmail 35252 Mar 17
13:46 qmail-inject
-rwx--x--x 1 root qmail 34396 Mar 17
13:46 qmail-local
-rwx------ 1 root qmail 17532 Mar 17
13:46 qmail-lspawn
-rwx------ 1 root qmail 14308 Mar 17
13:46 qmail-newmrh
-rwx------ 1 root qmail 11584 Mar 17
13:46 qmail-newu
-rwxr-xr-x 1 root qmail 19108 Mar 17
13:46 qmail-pop3d
-rwx--x--x 1 root qmail 11556 Mar 17
13:46 qmail-popup
-rwx--x--x 1 root qmail 16184 Mar 17
13:46 qmail-pw2u
-rwxr-xr-x 1 root qmail 13084 Mar 17
13:46 qmail-qmqpc
-rwxr-xr-x 1 root qmail 14016 Mar 17
13:46 qmail-qmqpd
-rwxr-xr-x 1 root qmail 21316 Mar 17
13:46 qmail-qmtpd
-rwxr-xr-x 1 root qmail 15368 Mar 17
13:46 qmail-qread
-rwxr-xr-x 1 root qmail 371 Mar 17
13:46 qmail-qstat
-rws--x--x 1 qmailq qmail 12908 Mar 17
13:46 qmail-queue
-rwx--x--x 1 root qmail 25444 Mar 17
13:46 qmail-remote
-rwx--x--x 1 root qmail 13452 Mar 17
13:46 qmail-rspawn
-rwx--x--x 1 root qmail 40748 Mar 17
13:46 qmail-send
-rwxr-xr-x 1 root qmail 16368 Mar 17
13:46 qmail-showctl
-rwxr-xr-x 1 root qmail 26488 Mar 17
13:46 qmail-smtpd
-rwx------ 1 root qmail 5724 Mar 17
13:46 qmail-start
-rwxr-xr-x 1 root qmail 9236 Mar 17
13:46 qmail-tcpok
-rwxr-xr-x 1 root qmail 10396 Mar 17
13:46 qmail-tcpto
-rwxr-xr-x 1 root root 3439 Feb 18
23:58 qmailctl
-rwxr-xr-x 1 root qmail 21736 Mar 17
13:46 qreceipt
-rwxr-xr-x 1 root qmail 11428 Mar 17
13:46 qsmhook
-rwxr-xr-x 1 root qmail 9628 Mar 17
13:46 sendmail
-rwx--x--x 1 root qmail 6548 Mar 17
13:46 splogger
-rwxr-xr-x 1 root qmail 17276 Mar 17
13:46 tcp-env

Here is the log for the error:

@400000003c9491100905883c new msg 33382
@400000003c9491100905c6bc info msg 33382: bytes 1358
from <flemaire@skolia.com> qp 517 uid 71
@400000003c9491100952e4ec starting delivery 3: msg
33382 to remote flemaire@activsoft.fr
@400000003c94911009531f84 status: local 0/10 remote
1/20
@400000003c94911009607594 delivery 3: failure:
Unable_to_run_qmail-remote./
@400000003c9491100960ac44 status: local 0/10 remote
0/20
@400000003c94911009fdcaec bounce msg 33382 qp 519
@400000003c9491100a0135ec end msg 33382
@400000003c9491100a0ab784 new msg 33388
@400000003c9491100a0eca7c info msg 33388: bytes 1890
from <> qp 519 uid 72
@400000003c9491100a865bdc starting delivery 4: msg
33388 to local flemaire@skolia.com
@400000003c9491100a899414 status: local 1/10 remote
0/20
@400000003c9491100b598a5c delivery 4: success:
did_1+0+0/
@400000003c9491100b5e6c5c status: local 0/10 remote
0/20
@400000003c9491100b648eac end msg 33388

Help greatly appreciated, once again.

Francois Lemaire

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: Unable to run qmail-remote [ In reply to ]
François Lemaire <sossalemaire@yahoo.fr> wrote:

> Now, I've got another one: unable to run qmail-remote.
> I have checked the mailing list archive and here are
> the solutions I tried:
>
> - run make setup check
> - check the permissions on /var/qmail/bin
> - check that qmail is run with /var/qmail/bin in the
> path (it is and I'm sure of it since local mail works)
> - repair the queue with queue-fix

Permissions look okay. Try stracing/trussing qmail-rspawn to see why it's
failing.

Charles
--
-----------------------------------------------------------------------
Charles Cazabon <qmail@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------
Re: Unable to run qmail-remote [ In reply to ]
Here is the result of strace on qmail-rspawn:

select(1, [0], NULL, NULL, NULL) = 1 (in [0])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
read(0, "\00014/33387\0flemaire@skolia.com\0fl"...,
1024) = 52
open("14/33387", O_RDONLY|O_NONBLOCK) = 2
fstat(2, {st_mode=S_IFREG|0644, st_size=1354, ...}) =
0
pipe([3, 4]) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
vfork() = 680
close(2) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
--- SIGCHLD (Child exited) ---
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 100],
WNOHANG, NULL) = 680
close(4) = 0
wait4(-1, 0xbffffbf8, WNOHANG, NULL) = -1 ECHILD
(No child processes)
sigreturn() = ? (mask now
[])
select(4, [0 3], NULL, NULL, NULL) = 1 (in [3])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
read(3, "", 128) = 0
write(1, "\0DUnable to run qmail-remote.\n\0", 31) =
31
close(3) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0


Does it mean something to you?

Rgds

Francois Lemaire

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: Unable to run qmail-remote [ In reply to ]
François Lemaire <sossalemaire@yahoo.fr> writes:

> Here is the result of strace on qmail-rspawn:

Try using the -f flag to strace, to follow the qmail-remote process
and see why it's dying.

-----ScottG.
Re: Unable to run qmail-remote [ In reply to ]
I got it! I had put var/qmail/bin in the PATH of my rc
script, not /var/qmail/bin.

Thanks for the advices.

Rgds

Francois Lemaire

--- Scott Gifford <sgifford@suspectclass.com> a
écrit : > François Lemaire <sossalemaire@yahoo.fr>
writes:
>
> > Here is the result of strace on qmail-rspawn:
>
> Try using the -f flag to strace, to follow the
> qmail-remote process
> and see why it's dying.
>
> -----ScottG.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: Unable to run qmail-remote [ In reply to ]
On Tue, 8 Aug 2006, Ian Eiloart wrote:

> For large mailing lists, "messages have, at most, a couple recipients, and
> they're usually on separate hosts," is not true either. Many of my large
> mailing lists have dozens of hotmail subscribers, for example. I guess that
> that's not "Most messages".

Even with large lists, the savings may not be great:

http://marc.theaimsgroup.com/?l=qmail&m=104337391928112&w=2

Rick.
Re: Unable to run qmail-remote [ In reply to ]
On Tuesday, August 8 at 12:17 PM, quoth Ian Eiloart:
>> There's more to it than that. If that was all it is, those would be
>> stupid reasons. There's a good discussion/justification of the
>> method and comparison to the alternatives here:
>> http://www.lifewithqmail.org/lwq.html#multi-rcpt
>>
>> It boils down to: it's *faster* as well as simpler.
>
> Really? Its faster to make six connections to a remote host to send the
> same email to six different people, than it is to make one connection and
> say "here's an email for these six people"?

Yes. And that webpage explains why:

>> That "wastes" bandwidth, but due to the nature of the SMTP
>> protocol, requires fewer round-trip delays, and is faster than the
>> third method.

Since you aren't paying attention, let me lay it out for you: as an
SMTP client, you MAY NOT send the next recipient until the server has
approved of the first. An SMTP conversation goes like this:

> HELO friend
...wait...
< 250 memoryhole.net
> MAIL FROM: <st.claus@north.pole>
...wait...
< 250 ok
> RCPT TO: <foo@bar.com>
...wait...
< 250 ok
> RCPT TO: <foo2@bar.com>
...wait...
< 250 ok
> DATA
...wait...
< 354 go ahead

...and so forth. Notice all those "...wait..." statements. You're NOT
allowed to proceed until the server responds. (This is somewhat helped
if the server supports the PIPELINING extension.)

If you send them as separate connections, the waiting can overlap.
Like so:

> HELO friend > HELO friend
...wait... ...wait...
< 250 memoryhole.net < 250 memoryhole.net
> MAIL FROM:<st.claus@north.pole> > MAIL FROM:<st.claus@north.pole>
...wait... ...wait...
< 250 ok < 250 ok
> RCPT TO: <foo@bar.com> > RCPT TO: <foo2@bar.com>
...wait... ...wait...
< 250 ok < 250 ok
> DATA > DATA
...wait... ...wait...
< 354 go ahead < 354 go ahead

Tada! The same information communicated with only four waits rather
than five.

> I guess that in some cases, where the remote host can parallelise
> the incoming streams, there may be a benefit. But usually not. The
> case is made in this paragraph:

If your host cannot parallelize incoming streams, then you deserve
what you get. As a *server*, you MUST be able to handle multiple
clients at the same time. Because we're dealing in I/O, there's going
to be a lot of lag-time for a single connection, so you basically have
no excuse for refusing to handle other connections at the same time. I
have no idea why you say "But usually not." about the prospects of a
*server* being able to handle multiple connections at the same time.
Go examine Apache, sendmail, postfix, openssh, and then come back and
tell me how many of them are incapable of handling multiple incoming
streams at the same time. (Hint: none of them.)

> I simply don't believe that "due to the nature of the SMTP protocol,
> [making a connection for each recipient] requires fewer round-trip
> delays,". That might be true *per message*, but there are many more
> messages required. In fact, for multiple recipients, it's one round
> trip per extra recipient - but sending a separate message is a
> connection, greeting, MAIL, RCPT, DATA and message.

Yes, sending a separate message is an extra connection, but it is not
extra WAITING. Instead you are using extra BANDWIDTH to decrease
LATENCY by doing your communication in PARALLEL. Please look up these
basic networking concepts before making an ass of yourself on a public
mailing list.

> For large mailing lists, "messages have, at most, a couple
> recipients, and they're usually on separate hosts," is not true
> either. Many of my large mailing lists have dozens of hotmail
> subscribers, for example. I guess that that's not "Most messages".

Okay, let's talk basic large mailing list policy. From
http://www.faqs.org/faqs/mail/list-admin/software-faq/ section 2.05:

Majordomo (a good example of the "leave-it-to-Sendmail" model),
once it decides to forward a message to a list, passes it to a
single Sendmail process along with the addresses for the entire
list. Sendmail then does what it can to optimize delivery (i.e.
sorting by MX record), and starts connecting to each machine in
series. The result on a 200-subscriber list, with everyone in the
U.S. and most with different mail exchangers, is that there's
about an hour's delay between the first delivery and the last.

Yikes!

ListProc speeds up the delivery process for large lists by passing
each message off to your MTA (usually Sendmail, but ListProc
doesn't care, it just connects to port 25 with SMTP) in chunks of
N addresses, where N is defineable. Depending on how the MTA is
configured, delivery will usually be faster because deliveries are
parallelized -- the longest list is of size N. However, Sendmail
can't optimize deliveries as much, because no particular Sendmail
process has the entire list to work with. Thus network efficiency
can go down (not actually a big problem, because ListProc produces
"chunks" sorted by domain).

In qmail, this is not a problem, because each recipient is treated
independently (excluding the host-backoff scheme). It is not
*efficient*, but the throughput is very high, and that's what really
matters.

The question is: how optimized can your mailing list be for your
"dozens of Hotmail subscribers"? Do you use VERP? If you do use VERP
(a *very* good idea) then you get no benefit from multi-recipient
messages to the same host. If not, how do you track which users are
reachable and which are not---parsing bounce messages? How much do you
pay, in terms of CPU time, to handle those bounce messages? If you do
not parse bounce messages, what sort of a penalty do you pay for
sending messages that you could have known would not succeed?

~Kyle
--
Disobedience, in the eyes of any one who has read history, is man's
original virtue. It is through disobedience that progress has been
made, through disobedience and through rebellion.
-- Oscar Wilde
Re: Unable to run qmail-remote [ In reply to ]
On Tuesday, August 8 at 11:12 AM, quoth Kyle Wheeler:
> In qmail, this is not a problem, because each recipient is treated
> independently (excluding the host-backoff scheme). It is not
> *efficient*, but the throughput is very high, and that's what really
> matters.

I should add that it depends on what you're optimizing, and what your
constraints are. If you are bandwidth-limited, then you may get higher
throughput by condensing your messages to the same host, if only
because you can get more messages out per unit of time that way.
However, on most networks, SMTP represents less than half of the
network traffic (I don't have the exact number handy, but I believe
it's usually something like 8-15%). As such, using a little extra
bandwidth to reduce latency is a solid win.

~Kyle
--
We must not confuse dissent with disloyalty. When the loyal opposition
dies, I think the soul of America dies with it.
-- Edward R. Murrow
Re: Unable to run qmail-remote [ In reply to ]
--On 8 August 2006 11:12:29 -0400 Kyle Wheeler <kyle-qmail@memoryhole.net>
wrote:

> On Tuesday, August 8 at 12:17 PM, quoth Ian Eiloart:
>>> There's more to it than that. If that was all it is, those would be
>>> stupid reasons. There's a good discussion/justification of the
>>> method and comparison to the alternatives here:
>>> http://www.lifewithqmail.org/lwq.html#multi-rcpt
>>>
>>> It boils down to: it's *faster* as well as simpler.
>>
>> Really? Its faster to make six connections to a remote host to send the
>> same email to six different people, than it is to make one connection
>> and say "here's an email for these six people"?
>
> Yes. And that webpage explains why:
>
>>> That "wastes" bandwidth, but due to the nature of the SMTP
>>> protocol, requires fewer round-trip delays, and is faster than the
>>> third method.
>
> Since you aren't paying attention,

I am paying attention. Please don't be rude. I count 8 waits, not four.

Parallelised, maybe, depending on whether the remote server lets you do
that. Mine does, to a limit of a few connections, in order to prevent
denial of service attacks. Beyond that, you have to wait just to get the
connection.

And, more to the point, qmail screws up badly when it can't launch enough
processes - bouncing my mail instead of delivering it. In the end, it took
days, not minutes to get my ONE message to fifty recipients. And it took me
fifteen minutes of real to resend the message without duplication.

> let me lay it out for you: as an SMTP
> client, you MAY NOT send the next recipient until the server has approved
> of the first. An SMTP conversation goes like this:
>
> > HELO friend
> ...wait...
> < 250 memoryhole.net
> > MAIL FROM: <st.claus@north.pole>
> ...wait...
> < 250 ok
> > RCPT TO: <foo@bar.com>
> ...wait...
> < 250 ok
> > RCPT TO: <foo2@bar.com>
> ...wait...
> < 250 ok
> > DATA
> ...wait...
> < 354 go ahead
>
> ...and so forth. Notice all those "...wait..." statements. You're NOT
> allowed to proceed until the server responds. (This is somewhat helped if
> the server supports the PIPELINING extension.)
>
> If you send them as separate connections, the waiting can overlap. Like
> so:
>
> > HELO friend > HELO friend
> ...wait... ...wait...
> < 250 memoryhole.net < 250 memoryhole.net
> > MAIL FROM:<st.claus@north.pole> > MAIL FROM:<st.claus@north.pole>
> ...wait... ...wait...
> < 250 ok < 250 ok
> > RCPT TO: <foo@bar.com> > RCPT TO: <foo2@bar.com>
> ...wait... ...wait...
> < 250 ok < 250 ok
> > DATA > DATA
> ...wait... ...wait...
> < 354 go ahead < 354 go ahead
>
> Tada! The same information communicated with only four waits rather than
> five.
>
>> I guess that in some cases, where the remote host can parallelise
>> the incoming streams, there may be a benefit. But usually not. The
>> case is made in this paragraph:
>
> If your host cannot parallelize incoming streams, then you deserve what
> you get. As a *server*, you MUST be able to handle multiple clients at
> the same time. Because we're dealing in I/O, there's going to be a lot of
> lag-time for a single connection, so you basically have no excuse for
> refusing to handle other connections at the same time. I have no idea why
> you say "But usually not." about the prospects of a *server* being able
> to handle multiple connections at the same time. Go examine Apache,
> sendmail, postfix, openssh, and then come back and tell me how many of
> them are incapable of handling multiple incoming streams at the same
> time. (Hint: none of them.)
>
>> I simply don't believe that "due to the nature of the SMTP protocol,
>> [making a connection for each recipient] requires fewer round-trip
>> delays,". That might be true *per message*, but there are many more
>> messages required. In fact, for multiple recipients, it's one round
>> trip per extra recipient - but sending a separate message is a
>> connection, greeting, MAIL, RCPT, DATA and message.
>
> Yes, sending a separate message is an extra connection, but it is not
> extra WAITING. Instead you are using extra BANDWIDTH to decrease LATENCY
> by doing your communication in PARALLEL. Please look up these basic
> networking concepts before making an ass of yourself on a public mailing
> list.

Please look up basic courtesy concepts before doing likewise.

.....
> that's what really matters.
>
> The question is: how optimized can your mailing list be for your "dozens
> of Hotmail subscribers"? Do you use VERP? If you do use VERP (a *very*
> good idea) then you get no benefit from multi-recipient messages to the
> same host.

Yes, actually I do use VERP. I have a choice of doing that in Mailman or
Exim. Currently I do it in Mailman, but I don't like that because it means
handing putting a message per recipient into the outgoing Mailman queue.
I'm planning on doing it in the Exim config instead. But that's off topic.

> If not, how do you track which users are reachable and which
> are not---parsing bounce messages? How much do you pay, in terms of CPU
> time, to handle those bounce messages? If you do not parse bounce
> messages, what sort of a penalty do you pay for sending messages that you
> could have known would not succeed?
>
> ~Kyle



--
Ian Eiloart
IT Services, University of Sussex
Re: Unable to run qmail-remote [ In reply to ]
On Tuesday, August 8 at 05:07 PM, quoth Ian Eiloart:
> I am paying attention. Please don't be rude. I count 8 waits, not
> four.

Total time spent waiting divided by the round-trip-time equals: 4
waits. What matters is the total time spent sending message X to both
recipients.

> Parallelised, maybe, depending on whether the remote server lets you
> do that.

Other than intentional limits (and the limits, if you're only trying
to prevent denial of service, can be pretty high-20 or more), what
mail server cannot handle multiple connections? You keep suggesting
that parallel network connections are some bizarre, rare event. Why?

> Mine does, to a limit of a few connections, in order to prevent
> denial of service attacks. Beyond that, you have to wait just to get
> the connection.

I know, I know, draconian connection limiting is a misguided anti-spam
policy that has been spreading relatively recently at a few
universities and small companies (usually based, as best I can tell,
on a recommendation by Barracuda Spam Firewalls), but that makes it
neither a good idea nor something we should optimize for.

Put it this way: qmail's been a part of the scene (in its current
incarnation, with its current policies and behaviors) since at least
1998. Depending on what survey you read, it's either the #2 mail
server in the world, or the #3. Multiple connections from a single
host, therefore, is not only common, but to be expected. Designing a
mail server that cannot handle or permit that is *BROKEN*. This is
going to become more and more the case as NAT installations become
more common for companies as part of a way of reducing costs (no need
to purchase an entire IP range), increasing security (harder to meddle
with your unsecured windows machines if you can't address them
directly), and dealing with the exhaustion of the IPv4 address space.

If I send you two SYN packets from different source ports at roughly
the same time, I expect that those ACK packets will come back at
roughly the same time. I don't have to wait extra long to open two
connections, unless you've set up some sort of filter that refuses to
respond to the second SYN. The time to set up twenty connections,
assuming your system isn't broken (or overloaded), should be
approximately the same time necessary to set up a single connection.

> And, more to the point, qmail screws up badly when it can't launch enough
> processes - bouncing my mail instead of delivering it. In the end, it took
> days, not minutes to get my ONE message to fifty recipients. And it took me
> fifteen minutes of real to resend the message without duplication.

?

I have *never* had that kind of trouble with qmail. On an average day,
my queue mostly consists of mailing list messages that are 99%
complete and are waiting for that last mistyped email address (e.g.
hotmailk.com) to time-out. For direct comparison to your experience,
the average qtime for my (small) 400-recipient mailing lists is
549.284 seconds per message (lists without incorrect addresses
complete much faster, on average). My concurrencyremote is the
default, 20 processes. Something very odd must have happened to your
setup.

>> The question is: how optimized can your mailing list be for your
>> "dozens of Hotmail subscribers"? Do you use VERP? If you do use
>> VERP (a *very* good idea) then you get no benefit from
>> multi-recipient messages to the same host.
>
> Yes, actually I do use VERP. I have a choice of doing that in Mailman or
> Exim. Currently I do it in Mailman, but I don't like that because it means
> handing putting a message per recipient into the outgoing Mailman queue.
> I'm planning on doing it in the Exim config instead. But that's off topic.

So, in other words, you're an exim user badmouthing qmail on the qmail
list? HEH. I believe there's a common term for that sort of behavior.

Because you're using VERP, you're not even benefiting from any
advantages condensing messages with multiple recipients might net you.
What's your beef here?

~Kyle
--
Every American expects and deserves clean air, and then we act on that
belief, then we will set an example for the rest of the world to
follow.
-- George H. W. Bush
Re: Unable to run qmail-remote [ In reply to ]
--On 8 August 2006 12:55:23 -0400 Kyle Wheeler <kyle-qmail@memoryhole.net>
wrote:

> Put it this way: qmail's been a part of the scene (in its current
> incarnation, with its current policies and behaviors) since at least
> 1998. Depending on what survey you read, it's either the #2 mail server
> in the world, or the #3.

Or 17th

<http://www.falkotimme.com/projects/survey_smtp_032004.php>

But I'd not put any value in such surveys. Witness the recent decline in
Apache "popularity" as a result of one hosting provider deciding to switch.
--
Ian Eiloart
IT Services, University of Sussex
Re: Unable to run qmail-remote [ In reply to ]
>> And, more to the point, qmail screws up badly when it can't launch
>> enough processes - bouncing my mail instead of delivering it. In the
>> end, it took days, not minutes to get my ONE message to fifty
>> recipients. And it took me fifteen minutes of real to resend the
>> message without duplication.
>
> ?
>
> I have *never* had that kind of trouble with qmail. On an average day,
> my queue mostly consists of mailing list messages that are 99% complete
> and are waiting for that last mistyped email address (e.g. hotmailk.com)
> to time-out. For direct comparison to your experience, the average qtime
> for my (small) 400-recipient mailing lists is 549.284 seconds per
> message (lists without incorrect addresses complete much faster, on
> average). My concurrencyremote is the default, 20 processes. Something
> very odd must have happened to your setup.

You forgot that he is not using qmail but something that was originally
qmail. Most likely patched/modified beyond recognition.
Re: Unable to run qmail-remote [ In reply to ]
--On 10 August 2006 11:32:37 +0800 Feizhou <feizhou@graffiti.net> wrote:

>
>>> And, more to the point, qmail screws up badly when it can't launch
>>> enough processes - bouncing my mail instead of delivering it. In the
>>> end, it took days, not minutes to get my ONE message to fifty
>>> recipients. And it took me fifteen minutes of real to resend the
>>> message without duplication.
>>
>> ?
>>
>> I have *never* had that kind of trouble with qmail. On an average day,
>> my queue mostly consists of mailing list messages that are 99% complete
>> and are waiting for that last mistyped email address (e.g. hotmailk.com)
>> to time-out. For direct comparison to your experience, the average qtime
>> for my (small) 400-recipient mailing lists is 549.284 seconds per
>> message (lists without incorrect addresses complete much faster, on
>> average). My concurrencyremote is the default, 20 processes. Something
>> very odd must have happened to your setup.
>
> You forgot that he is not using qmail but something that was originally
> qmail. Most likely patched/modified beyond recognition.

So, what does vanilla qmail do with an email when it can't launch
qmail-send?

--
Ian Eiloart
IT Services, University of Sussex
Re: Unable to run qmail-remote [ In reply to ]
On Thu, Aug 10, 2006 at 11:02:44AM +0100, Ian Eiloart wrote:
> So, what does vanilla qmail do with an email when it can't launch
> qmail-send?

qmail-send is the master daemon that processes the queue and runs
qmail-lspawn and qmail-rspawn. If it can't run, then the queue simply
never gets processed.

If qmail-remote dies when qmail-rspawn forks it, then the delivery
attempt is treated the same as any other temporary error. If you
continue having concurrency issues, the messages may eventually bounce.
Re: Unable to run qmail-remote [ In reply to ]
--On 10 August 2006 08:34:07 -0500 "Matthew R. Dempsky" <mrd@alkemio.org>
wrote:

> On Thu, Aug 10, 2006 at 11:02:44AM +0100, Ian Eiloart wrote:
>> So, what does vanilla qmail do with an email when it can't launch
>> qmail-send?
>
> qmail-send is the master daemon that processes the queue and runs
> qmail-lspawn and qmail-rspawn. If it can't run, then the queue simply
> never gets processed.
>
> If qmail-remote dies when qmail-rspawn forks it, then the delivery
> attempt is treated the same as any other temporary error. If you
> continue having concurrency issues, the messages may eventually bounce.

Ah, yes it's qmail-remote that doesn't launch. My messages get bounced
immediately as if a permanent error had occurred, so maybe that's one thing
that's been changed with a patch. Very strange thing to be changing, though.

--
Ian Eiloart
IT Services, University of Sussex
Re: Unable to run qmail-remote [ In reply to ]
Hello John,

Wednesday, December 20, 2017, 7:13:55 PM, you wrote:

JL> That suggests it's crashing. Look for a core dump file.

Where?

JL> The ventura-uk.com mail server sends prompts full of stars and X's
JL> which suggests it's behind some sort of braindead "transparent"
JL> firewall, but qmail-remote should give up in disgust, not crash.

Some of those responses are weird!

JL> It might also be informative to run qmail-remote directly with
JL> appropriate arguments and input file and see what happens. With any
JL> luck it'll crash on demand, and then you can figure out what's wrong.

How? We're successfully sending email everywhere else so it's just this
server, thing is we email a remittance advice to it maybe 2-3 times a
year.

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Unable to run qmail-remote [ In reply to ]
Hello John,

Thursday, December 21, 2017, 3:50:50 PM, you wrote:

JL> $ /var/qmail/bin/qmail-remote ventura-uk.com
JL> postmaster@fullbore.co.uk tradeuk@ventura-uk.com < foo

Shouldn't that be $ /var/qmail/bin/qmail-remote mail.ventura-uk.com postmaster@fullbore.co.uk tradeuk@ventura-uk.com < foo


--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Unable to run qmail-remote [ In reply to ]
Hello,

Thursday, December 21, 2017, 3:50:50 PM, you wrote:

JL> $ /var/qmail/bin/qmail-remote ventura-uk.com
JL> postmaster@fullbore.co.uk tradeuk@ventura-uk.com < foo

/var/qmail/bin/qmail-remote: line 88: 21977 Segmentation fault "$DKREMOTE" "$@" < "$tmp3"

But sending the same message to my gmail address works fine-

rK74.125.140.27 accepted message.
Remote host said: 250 2.0.0 OK 1513952784 41si3073625wrt.321 - gsmtp

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Unable to run qmail-remote [ In reply to ]
Niamh Holding <niamh@fullbore.co.uk> wrote:
>
> JL> $ /var/qmail/bin/qmail-remote ventura-uk.com
> JL> postmaster@fullbore.co.uk tradeuk@ventura-uk.com < foo
>
> /var/qmail/bin/qmail-remote: line 88: 21977 Segmentation fault "$DKREMOTE" "$@" < "$tmp3"
>
> But sending the same message to my gmail address works fine-
>
> rK74.125.140.27 accepted message.
> Remote host said: 250 2.0.0 OK 1513952784 41si3073625wrt.321 - gsmtp

Sounds like you have a buggy patch applied to qmail, then. If it was some
other cause - like hardware issues - it wouldn't always succeed with one
domain and fail with the other.

Finding out which patch or combination of patches causes the bug will not be
simple. You may wish to try reverting to vanilla qmail and add the patches
you need back in one at a time -- i.e., don't use a big combined patch, just
patch in the features you need. Add a patch, run the test case - if it
doesn't crash, move on to the next patch, etc. Once it starts crashing,
you've found it.

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
--------------------------------------------------------------------------
Re: Unable to run qmail-remote [ In reply to ]
Hello Charles,

Saturday, December 23, 2017, 4:11:07 AM, you wrote:

CC> Finding out which patch or combination of patches causes the bug will not be
CC> simple.

I think I know and it's probably not handliny the garbage EHLO response...

From https://qmail.jms1.net/patches/combined-details.shtml

Tom Clegg's qmail-remote-auth.patch allows qmail-remote to use AUTH when
connecting to certain remote mail servers. The userids and passwords are
set in the "smtproutes" file, after the IP[:PORT] value, separated by
spaces. For example...

domain1.xyz:1.2.3.4
domain2.xyz:2.3.4.5 user pass
domain3.xyz:3.4.5.6:26 user pass

In the process of tracking down what I thought was a bug, I ended up
adding support for the AUTH PLAIN method. With this patch, qmail-remote
checks the list of AUTH methods advertised in the EHLO response, and can
work with either AUTH PLAIN or AUTH LOGIN (with AUTH PLAIN being used if
both are available.) This was made possible by the regex function from
above, because using regular expressions makes it so much easier to scan
the server's output for authentication methods.

I also found something else which may be a bug or may have been by design,
but it doesn't seem right to me so I changed it. When it sends the "MAIL
FROM:<...> AUTH=<...>" line (after successfully AUTH'ing to the remote
server) it was repeating the sender address in the AUTH= argument, rather
than putting the actual AUTH information in this argument. It now puts the
userid from the AUTH information into the AUTH= argument. If this is
somehow wrong, please explain to me why and I'll change it back.

--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Unable to run qmail-remote [ In reply to ]
Hi Niamh,

some of the Auth packages for qmail are buggy; some calculate the wrong MD5 hashsums given a 64 bit OS.

You can try to use mine:

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

A little bit outdated considering my s/qmail

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

but still ok.

Regards.
--eh.

BTW: DKIM support will come with aQmail.


> Am 23.12.2017 um 09:21 schrieb Niamh Holding <niamh@fullbore.co.uk>:
>
>
> Hello Charles,
>
> Saturday, December 23, 2017, 4:11:07 AM, you wrote:
>
> CC> Finding out which patch or combination of patches causes the bug will not be
> CC> simple.
>
> I think I know and it's probably not handliny the garbage EHLO response...
>
> From https://qmail.jms1.net/patches/combined-details.shtml
>
> Tom Clegg's qmail-remote-auth.patch allows qmail-remote to use AUTH when
> connecting to certain remote mail servers. The userids and passwords are
> set in the "smtproutes" file, after the IP[:PORT] value, separated by
> spaces. For example...
>
> domain1.xyz:1.2.3.4
> domain2.xyz:2.3.4.5 user pass
> domain3.xyz:3.4.5.6:26 user pass
>
> In the process of tracking down what I thought was a bug, I ended up
> adding support for the AUTH PLAIN method. With this patch, qmail-remote
> checks the list of AUTH methods advertised in the EHLO response, and can
> work with either AUTH PLAIN or AUTH LOGIN (with AUTH PLAIN being used if
> both are available.) This was made possible by the regex function from
> above, because using regular expressions makes it so much easier to scan
> the server's output for authentication methods.
>
> I also found something else which may be a bug or may have been by design,
> but it doesn't seem right to me so I changed it. When it sends the "MAIL
> FROM:<...> AUTH=<...>" line (after successfully AUTH'ing to the remote
> server) it was repeating the sender address in the AUTH= argument, rather
> than putting the actual AUTH information in this argument. It now puts the
> userid from the AUTH information into the AUTH= argument. If this is
> somehow wrong, please explain to me why and I'll change it back.
>
> --
> Best regards,
> Niamh mailto:niamh@fullbore.co.uk

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: EE00CF65