qmail Digest 12 Oct 1999 10:00:01 -0000 Issue 787
Topics (messages 31489 through 31529):
Re: qmail-inject: fatal: qq read error (#4.3.0)
31489 by: Vince Vielhaber
Re: getting qmail to retry
31490 by: Sam
31495 by: Claus F�rber
31505 by: Sam
31514 by: Claus F�rber
31517 by: Sam
dot before @
31491 by: Andre Oppermann
31501 by: Bruno Wolff III
31509 by: Claus F�rber
31511 by: Andre Oppermann
31513 by: Brad Shelton
31518 by: Claus F�rber
Anti Spamming
31492 by: FONR
31497 by: Magnus Bodin
Re: control/{locals,rcpthosts,virtualdomains}
31493 by: Mikko H�nninen
31494 by: Russell Nelson
Re: Sqwebmail and IMAP
31496 by: Claus F�rber
31504 by: Sam
31512 by: Russell Nelson
31515 by: Claus F�rber
31516 by: Sam
31519 by: Claus F�rber
31522 by: Sam
31524 by: Tim Tsai
31525 by: Russell Nelson
About relaying after POP
31498 by: Paulo Jan
Re: inetd
31499 by: Marco Leeflang
31503 by: Todd A. Jacobs
Re: problem with svscan in daemontools 0.61
31500 by: Mate Wierdl
Qmail 1.01 ignores percenthack settings
31502 by: Craig Shrimpton
those damn hackers
31506 by: B. Engineer
31507 by: Timothy L. Mayo
31510 by: B. Engineer
Removing messages from the queue (another one)
31508 by: Wallace Nicoll
alias header mods causing problems
31520 by: James Smallacombe
Re: Qmail-Inject error related to Datemail
31521 by: Peter Samuel
qmail fail when start with supervise?
31523 by: victor.outblaze.com
Yes, inetd DOES work!
31526 by: Todd A. Jacobs
Setup HotMail by Qmail ?
31527 by: ftien.tomail.com.tw
supervise/qmail shutdown tasks?
31528 by: A Curtin
MX --> IP number instead of host name
31529 by: Fred Backman
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
On Sun, 10 Oct 1999, Vince Vielhaber wrote:
>
> What are some possible causes for this error?
>
> qmail-inject: fatal: qq read error (#4.3.0)
>
> Friday everything was fine, today I can't send mail. The above was
> from /var/qmail/bin/mailsubj, but I get the same from pine. Mail is
> coming in just fine it's just locally generated mail (and it's not
> going thru smtp).
>
> I've run make setup check figuring something may have changed, no go.
> There's plenty of disk space too. Anyone have an idea?
>
> Vince.
>
Following up to my own.. There was an odd message in the queue consisting
of only a Received line and a dot. It was also the only message there,
so I dumped the entire queue directory and did a make setup check and all
is well again.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null
# include <std/disclaimers.h> Have you seen http://www.pop4.net?
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
On Mon, 11 Oct 1999, Phil Howard wrote:
> Sam replied:
>
> > On Sun, 10 Oct 1999, Phil Howard wrote:
> >
> > > > This is not up to you. The remote server responded with a permanent
> > > > failure code. The mail gets bounced.
> > >
> > > I understand that it is a permanent failure code. But clearly a full
> > > mailbox is not a true permanent situation (although a spammer case is
> >
> > This is not your call. It is the receiving mail server that gets to
> > decide what is a permanent failure, and what is a temporary failure.
>
> But my server can decide whether to bounce it now or requeue it and try
> again later as if it were a temporary error.
Then it wouldn't be a server that implements SMTP.
> >
> > Well, yes. It's called RFC 822. It specifies that all 4xx error codes
> > are temporary failures, and that all 5xx error codes are permanent
> > failures.
>
> I mean a programmed table in qmail, where it specifies the internal routines
> for the action. If such a table is in a config file, I could change it
> there. If it is in the code, I can change it there. If it's not organized
> that way, I guess I'll have to code explicit checks.
Of course it's not organized that way, because SMTP servers do not have
any need for that. They just look at the numeric code, 4xx or 5xx, and
take one of two possible actions.
--
Sam
Phil Howard <[EMAIL PROTECTED]> schrieb/wrote:
> I understand that it is a permanent failure code. But clearly a full
> mailbox is not a true permanent situation.
Usually, this is upon the receiving MTA to decide. If it thinks that it
is not really permanent, it will send a 452 response instead of 552.
> What I was looking for is if there was a table of response codes and
> how to act when receiving them. Because of scattered documentation
> for qmail that means I haven't yet found everything, ...
Well, if you write or modify an implementation of a protocol, you should
read and understand the protocol specification.
For SMTP, this is RFC 821 and ist designated successor draft-ietf-drums-
smtpup-10.txt:
ftp://ftp.isi.edu/in-notes/rfc821.txt
http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpud-10.txt
And yes, you will have to hack qmail-remote for this.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
On 11 Oct 1999, ([ISO-8859-1] Claus F�rber) wrote:
> For SMTP, this is RFC 821 and ist designated successor draft-ietf-drums-
> smtpup-10.txt:
>
> ftp://ftp.isi.edu/in-notes/rfc821.txt
> http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpud-10.txt
That draft doesn't exist.
On second thought, I really don't want to know what these people want to
do with SMTP. Ugh, what a frightening thought...
--
Sam
Sam <[EMAIL PROTECTED]> schrieb/wrote:
> On 11 Oct 1999, ([ISO-8859-1] Claus F�rber) wrote:
>> http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpud-10.txt
> That draft doesn't exist.
http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpupd-10.txt
^
Sorry, mistyped the URI.
> On second thought, I really don't want to know what these people want to
> do with SMTP. Ugh, what a frightening thought...
It's not a new version of SMTP if that is what you're afraid of. It only
collects some important extensions (such as Extended SMTP/EHLO) and
clarifications.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
=?ISO-8859-1?Q?Claus_F=E4rber?= writes:
> > On second thought, I really don't want to know what these people want to
> > do with SMTP. Ugh, what a frightening thought...
>
> It's not a new version of SMTP if that is what you're afraid of. It only
> collects some important extensions (such as Extended SMTP/EHLO) and
> clarifications.
No, it does more than just that. I just read it. My initial suspicions
were correct.
--
Sam
Hi
I have this problem:
A customer has an virtual domain on our mailserver (qmail-ldap 1.03,
ldap has no nothing to do with it) but we forward all mail to an
external address (Netscape Messaging Server).
His email address on the remote server is <[EMAIL PROTECTED]>
(yes, with an dot before the at).
OK, so far so good and it works. BUT as soon as the message enters
our qmail system the local part gets quoted, it looks then like this:
<"vonbueren.rm."@bluewin.ch>.
Now the remote server doesn't like that and tells me "550 Invalid
recipient".
Who is wrong now? qmail for quoting the local part (which is legal
AFAIK) or is it Netscape's Messaging Server for not decoding the
quoted local part?
I don't have a problem telling the customer he is wrong but I want
to be sure that I'm right. :-)
--
Andre
On Mon, Oct 11, 1999 at 02:06:34PM +0200,
Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
> I have this problem:
>
> His email address on the remote server is <[EMAIL PROTECTED]>
> (yes, with an dot before the at).
The above is an illegal encoding of the address:
[EMAIL PROTECTED]
Dots are required to have words on both sides in the local part of the
address.
> OK, so far so good and it works. BUT as soon as the message enters
> our qmail system the local part gets quoted, it looks then like this:
> <"vonbueren.rm."@bluewin.ch>.
That is a valid rfc 821 encoding of the address:
[EMAIL PROTECTED]
> Now the remote server doesn't like that and tells me "550 Invalid
> recipient".
> Who is wrong now? qmail for quoting the local part (which is legal
> AFAIK) or is it Netscape's Messaging Server for not decoding the
> quoted local part?
Assuming there is a valid user of vonbueren.rm. at bluewin.ch, the Netscape
server is broken. However it may be that the person is advertising the wrong
email address for themselves.
Andre Oppermann <[EMAIL PROTECTED]> schrieb/wrote:
> Who is wrong now? qmail for quoting the local part (which is legal
> AFAIK) or is it Netscape's Messaging Server for not decoding the
> quoted local part?
It's Netscape again. Local parts that are not dot-atom strings (which
can't start or end with a dot) must be encoded, which qmail does
correctly.
A server not accepting local-parts in encoded form is seriously broken.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
Claus F�rber wrote:
>
> Andre Oppermann <[EMAIL PROTECTED]> schrieb/wrote:
> > Who is wrong now? qmail for quoting the local part (which is legal
> > AFAIK) or is it Netscape's Messaging Server for not decoding the
> > quoted local part?
>
> It's Netscape again. Local parts that are not dot-atom strings (which
> can't start or end with a dot) must be encoded, which qmail does
> correctly.
>
> A server not accepting local-parts in encoded form is seriously broken.
Ahh, great, that is what I wanted to hear! :-)
BTW, the time on your workstation looks pretty wrong, almost 19 hours
behind.
Cheers
--
Andre
On Mon, Oct 11, 1999 at 07:27:37PM +0200, Andre Oppermann wrote:
> Claus F�rber wrote:
> >
> > Andre Oppermann <[EMAIL PROTECTED]> schrieb/wrote:
> > > Who is wrong now? qmail for quoting the local part (which is legal
> > > AFAIK) or is it Netscape's Messaging Server for not decoding the
> > > quoted local part?
> >
> > It's Netscape again. Local parts that are not dot-atom strings (which
> > can't start or end with a dot) must be encoded, which qmail does
> > correctly.
> >
> > A server not accepting local-parts in encoded form is seriously broken.
>
> Ahh, great, that is what I wanted to hear! :-)
>
> BTW, the time on your workstation looks pretty wrong, almost 19 hours
> behind.
More like 13 hours.
--
Brad Shelton On Line Exchange http://online-isp.com
Brad Shelton <[EMAIL PROTECTED]> schrieb/wrote:
> > BTW, the time on your workstation looks pretty wrong, almost 19 hours
> > behind.
>
> More like 13 hours.
Well, exactly time-of-day hours. (My UA is configured to always send
00:00:00 -0000 for privacy reasons.)
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
Hi
Can any one tell me a solution for blocking mails on subject.
I have a customer who gets wierd mails form different sites , the mails
originate from different site everytime , thus i am not able to use the
badmail from feature as it is not a fixed site.
Any clue or help would be highly appreciated.
Thanks in advance
FONR
mailto:[EMAIL PROTECTED]
On Mon, Oct 11, 1999 at 06:17:24PM +0530, FONR wrote:
> Hi
> Can any one tell me a solution for blocking mails on subject.
> I have a customer who gets wierd mails form different sites , the mails
> originate from different site everytime , thus i am not able to use the
> badmail from feature as it is not a fixed site.
> Any clue or help would be highly appreciated.
Although I think blocking mail on subject is a really bad idea,
I would have installed procmail and give a .procmailrc as a present
to my customer:
#-----------------------
MAILDIR=$HOME/Mail
DEFAULT=$HOME/Mailbox
:0:
* ^Subject:.*broccoli.*
/dev/null
#-----------------------
(or if you use Maildir, substitute maildrop for procmail)
--
magnus
-- MOST useless 1998 * http://x42.com/
Franck PORCHER <[EMAIL PROTECTED]> wrote on Mon, 11 Oct 1999:
> What would be the best way to configure qmail to have this specific
> address ([EMAIL PROTECTED]) remotely delivered to my ISP (say "mail.pf"), so
> any local mail to
> [EMAIL PROTECTED] would eventually end-up in his remote mailbox. ?
Well, if there is no local user called "jean", you can create a file
~alias/.qmail-jean and put the address [EMAIL PROTECTED] (or whatever)
there. Any email to [EMAIL PROTECTED] will get forwarded to [EMAIL PROTECTED]
> I thought of putting
>
> [EMAIL PROTECTED]:alias-myisp
>
> in "control/virtualdomains",
No, you can't put usernames in control/virtualdomains. You can only use
full domain names. List the domains which should be handled virtually.
The delivery of those domains is controlled by the specified user (in
your case, ~alias-myisp, the ~alias/.qmail-myisp-* files).
Hope this helps,
Mikko
--
// Mikko H�nninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/
// The Corrs list maintainer // net.freak // DALnet IRC operator /
// Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs /
"Apple" (c) 6024 b.c., Adam & Eve
Mikko H�nninen writes:
> Franck PORCHER <[EMAIL PROTECTED]> wrote on Mon, 11 Oct 1999:
> > I thought of putting
> >
> > [EMAIL PROTECTED]:alias-myisp
> >
> > in "control/virtualdomains",
>
> No, you can't put usernames in control/virtualdomains.
As of qmail 1.03, you can. It's the replacement for recipientmap.
The purpose of this feature is to be able to override addresses which
would otherwise be sent elsewhere.
--
-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!
Sam <[EMAIL PROTECTED]> schrieb/wrote:
> Then what you will have to ask yourself is whether you want all your
> folders shared by every one of your incoming maildirs. I could consider
> the proposal of storing all folders in ../Mail, however what I don't like
> about this approach is that you're now in conflict with your mail apps who
> use $HOME/Mail to store traditional mailbox-file folders.
Which, when patched, will look for and store maildirs there, won't they?
And if you do use maildirs, all of your MUAs should be able to handle
maildirs or you won'tbe able to access your messages no matter where you
store them.
If you think of maildirs as an alternative to the mailbox _file_ format,
~/Mail/ is the obvious solution.
For folders that should contain both messages and subdirs, you could
create a subdirectory named ".default" to hold messages that
look as if they were stored in the parent folder. This is compatible
with MUAs that don't expect to see subfolders in maildirs (such as
mutt).
If you then fake a link from ~/Mail/.default/ or ~/Mail/INBOX/ (depends
on the protocol you're using/implementing) to $MAILDIR, you have a
complete hierarchical namespace.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
On 11 Oct 1999, ([ISO-8859-1] Claus F�rber) wrote:
> Sam <[EMAIL PROTECTED]> schrieb/wrote:
> > Then what you will have to ask yourself is whether you want all your
> > folders shared by every one of your incoming maildirs. I could consider
> > the proposal of storing all folders in ../Mail, however what I don't like
> > about this approach is that you're now in conflict with your mail apps who
> > use $HOME/Mail to store traditional mailbox-file folders.
>
> Which, when patched, will look for and store maildirs there, won't they?
> And if you do use maildirs, all of your MUAs should be able to handle
> maildirs or you won'tbe able to access your messages no matter where you
> store them.
>
> If you think of maildirs as an alternative to the mailbox _file_ format,
> ~/Mail/ is the obvious solution.
[ ... ]
And how would you propose handling a virtual mailbox farm, mailboxes that
have no dedicated system userid assigned to them?
It's not exactly obvious, is it?
> For folders that should contain both messages and subdirs, you could
> create a subdirectory named ".default" to hold messages that
> look as if they were stored in the parent folder. This is compatible
> with MUAs that don't expect to see subfolders in maildirs (such as
> mutt).
Most MUAs are now using IMAP, so this is quickly becoming irrelevant.
Despite that this is really an account that I normally use sqwebmail to
access, Pine has absolutely no problems reading Maildir, or accessing any
sqwebmail folder underneath Maildir. It simply logs on to the localhost
IMAP server, and uses whatever IMAP folders it sees.
> If you then fake a link from ~/Mail/.default/ or ~/Mail/INBOX/ (depends
> on the protocol you're using/implementing) to $MAILDIR, you have a
> complete hierarchical namespace.
No longer relevant. Any MUA worth its salt is capable of using IMAP,
right now, no matter how ugly IMAP really is. So, all you have to do is
standardize on an IMAP server, and the rest of your software will follow
through.
--
Sam
> Most MUAs are now using IMAP, so this is quickly becoming irrelevant.
IMAP is not appropriate for an ISP, because the ISP wants to get rid
of the email.
POP is not appropriate for a campus environment, because it's better
to control mail backups on a central server, and because IMAP works
with multiple clients (e.g. desktops and laptops, or work machines and
home machines).
I don't see either protocol going away.
--
-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!
Sam <[EMAIL PROTECTED]> schrieb/wrote:
> And how would you propose handling a virtual mailbox farm, mailboxes that
> have no dedicated system userid assigned to them?
> It's not exactly obvious, is it?
Where would you put mailbox files then? Simply put your maildirs there.
This is no less obvious if you consider maildirs a replacement for mbox
files.
> Most MUAs are now using IMAP, so this is quickly becoming irrelevant.
Then simply do whatever your imapd does and don't worry about
compatibility. On the other hand, maybe there are different IMAP
servers, web gateways etc. that should use the same strucutre.
In other words: Why use an incompatible format if you can use one that
is already there?
> No longer relevant. Any MUA worth its salt is capable of using IMAP,
> right now, no matter how ugly IMAP really is. So, all you have to do is
> standardize on an IMAP server,
Yes, and the best solution IMO is to use the "standard" that has already
been set by user agents.
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
=?ISO-8859-1?Q?Claus_F=E4rber?= writes:
> Sam <[EMAIL PROTECTED]> schrieb/wrote:
> > And how would you propose handling a virtual mailbox farm, mailboxes that
> > have no dedicated system userid assigned to them?
> > It's not exactly obvious, is it?
>
> Where would you put mailbox files then? Simply put your maildirs there.
I really don't care where I would put the mailbox files. I'm talking about
maildirs exclusively, and what makes the most amount of sense with
Maildirs. Putting maildirs somewhere where you normally keep mailbox files,
simply because of the deficiencies of the mailbox format, doesn't make
sense to me.
> > Most MUAs are now using IMAP, so this is quickly becoming irrelevant.
>
> Then simply do whatever your imapd does and don't worry about
> compatibility.
Since I am writing my imapd, this is my call.
> On the other hand, maybe there are different IMAP
> servers, web gateways etc. that should use the same strucutre.
>
> In other words: Why use an incompatible format if you can use one that
> is already there?
There is no established custom for maintaining maildir-based folders. As
far as I know, there are no IMAP servers who natively support maildirs.
The only thing I'm aware of is a patch to UW-IMAP. That does not a
standard make.
> > No longer relevant. Any MUA worth its salt is capable of using IMAP,
> > right now, no matter how ugly IMAP really is. So, all you have to do is
> > standardize on an IMAP server,
>
> Yes, and the best solution IMO is to use the "standard" that has already
> been set by user agents.
There is no such standard either. Every MUA I've seen does this
differently.
--
Sam
Russell Nelson <[EMAIL PROTECTED]> schrieb/wrote:
> > Most MUAs are now using IMAP, so this is quickly becoming irrelevant.
>
> IMAP is not appropriate for an ISP, because the ISP wants to get rid
> of the email.
Depends on the ISP. Some ISPs consider that additional value and do even
provide Webmail -- or mutt over ssh. ;-)
--
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC
=?ISO-8859-1?Q?Claus_F=E4rber?= writes:
> Russell Nelson <[EMAIL PROTECTED]> schrieb/wrote:
> > > Most MUAs are now using IMAP, so this is quickly becoming irrelevant.
> >
> > IMAP is not appropriate for an ISP, because the ISP wants to get rid
> > of the email.
>
> Depends on the ISP. Some ISPs consider that additional value and do even
> provide Webmail -- or mutt over ssh. ;-)
I think that most ISPs are reluctant to offer IMAP because UW-IMAP server
is such a bloated pig. I know for a fact that that's why at least one
major national ISP claimed was the major reason they declined to offer it.
--
Sam
> I think that most ISPs are reluctant to offer IMAP because UW-IMAP server
> is such a bloated pig. I know for a fact that that's why at least one
> major national ISP claimed was the major reason they declined to offer it.
There has also been a history of security problems with UW IMAP. "bloat"
I can live with, root security exploits I can not.
I haven't seen any reports of UW IMAP exploits for awhile though.
Tim
Sam writes:
> I think that most ISPs are reluctant to offer IMAP because UW-IMAP server
> is such a bloated pig.
In my experience, the IMAP protocol is the bloated pig.
--
-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!
Hi all:
Okay, last week I sent an email asking about how to configure Bruce
Guenter's "relay-ctrl" program to allow relaying after POP. This is just
to confirm that it's working now, and that the cause of the previous
malfunction was an error on my part: I had thought that
"/var/spool/relay-ctrl", which the program needs to operate, was a file,
when it was a directory. Once I created said directory, it worked
without problems.
Just in case it might be useful as reference for someone in the
future...
Paulo Jan.
DDnet.
don't use inetd but use tcpserver, see qmail-howto
http://www.flounder.net/qmail/qmail-howto.html
marco leeflang
"Todd A. Jacobs" wrote:
> As instructed by the installation guide, I placed an entry for smtp into
> inetd.conf. However, the entry:
>
> smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env \
> tcp-env /var/qmail/bin/qmail-smtpd
>
> doesn't seem to pay any attention to /etc/hosts.deny. I tried prefacing it
> with tcpd, but that didn't do much good either. Suggestions?
>
> --
> Todd A. Jacobs
> Network Systems Engineer
The problem seems to lie somewhere with tcp-env. Here is a line from my
logs:
Oct 10 23:23:57 tjacobs tcp-env[1184]: refused connect from
shell11.ba.best.com
So, it seems like tcp-env is actually refusing the connection. Any ideas
on how to debug this further?
--
Todd A. Jacobs
Network Systems Engineer
Is /usr/local/bin in PATH at the time the initscript is run?
Mate
Folks,
I have Qmail 1.01 with several patches (Qmail antispam and a fix for \n
termination) According to qmail-showctl, the percenthack is disabled.
However, it works for any IP on the server except for the actual fqdn of the
mail host. When I send a message to [EMAIL PROTECTED] (the
official name) I get a bounce saying no such user. When I send a message to
[EMAIL PROTECTED] (a virtual web host on same machine) it
sends the message.
I've tried with an empty percenthack file and no percenthack file. I can't
seem to disable percenthacks and now I'm on the ORBS list.
Is this a known issue with 1.01 or am I missing something? I want to turn
it off globally.
Thanks,
Craig
Hello:
Yesterday was the first time I got to test my qmail system with
the big to-do patch applied.
Problem:
Some $%^* hijacked a T1 line somewhere and started spamming using a
return address that points to my system. The sheer number of bounces
generated, slows legitimate mail down on my system by 6 hrs.
I had applied the big to-do patch in hopes of fixing that. My local
concurrency is set to 40 and remote to 120. I had 4000 messages in my
mail queue but qmail was not delivering mail for about 3 hrs. I had about
45 qmail-queue processes. The machine had plenty of juice, the load av.
never shot up over 1.5-2.0.
Local/Remote concurrency never shot up, logs showed a max of
2/40 and 6/120.
Can anyone explain this? I want qmail to chew/hog the cpu and deliver the
mail. What am I forgetting to tune??
Thanks
Burzin
What was your memory usage? What was your disk i/o like? Bandwidth to
the net? Could be any number of things.
Anything in your regular system logs during that time that might provide a
clue?
On Mon, 11 Oct 1999, B. Engineer wrote:
> Hello:
> Yesterday was the first time I got to test my qmail system with
> the big to-do patch applied.
>
> Problem:
> Some $%^* hijacked a T1 line somewhere and started spamming using a
> return address that points to my system. The sheer number of bounces
> generated, slows legitimate mail down on my system by 6 hrs.
>
> I had applied the big to-do patch in hopes of fixing that. My local
> concurrency is set to 40 and remote to 120. I had 4000 messages in my
> mail queue but qmail was not delivering mail for about 3 hrs. I had about
> 45 qmail-queue processes. The machine had plenty of juice, the load av.
> never shot up over 1.5-2.0.
> Local/Remote concurrency never shot up, logs showed a max of
> 2/40 and 6/120.
>
> Can anyone explain this? I want qmail to chew/hog the cpu and deliver the
> mail. What am I forgetting to tune??
>
> Thanks
> Burzin
>
>
---------------------------------
Timothy L. Mayo mailto:[EMAIL PROTECTED]
Senior Systems Administrator
localconnect(sm)
http://www.localconnect.net/
The National Business Network Inc. http://www.nb.net/
One Monroeville Center, Suite 850
Monroeville, PA 15146
(412) 810-8888 Phone
(412) 810-8886 Fax
On Mon, 11 Oct 1999, Timothy L. Mayo wrote:
> What was your memory usage? What was your disk i/o like? Bandwidth to
> the net? Could be any number of things.
>
> Anything in your regular system logs during that time that might provide a
> clue?
I was not thrashing. I beleive I had 400M of free memory. I am not sure
about the disk i/o. bandwidth to the net was plentiful. My queue is on a
local disk but the actual user mail boxes are on a NFS drive.
Nothing extraordinary in the logs.
> On Mon, 11 Oct 1999, B. Engineer wrote:
>
> > Hello:
> > Yesterday was the first time I got to test my qmail system with
> > the big to-do patch applied.
> >
> > Problem:
> > Some $%^* hijacked a T1 line somewhere and started spamming using a
> > return address that points to my system. The sheer number of bounces
> > generated, slows legitimate mail down on my system by 6 hrs.
> >
> > I had applied the big to-do patch in hopes of fixing that. My local
> > concurrency is set to 40 and remote to 120. I had 4000 messages in my
> > mail queue but qmail was not delivering mail for about 3 hrs. I had about
> > 45 qmail-queue processes. The machine had plenty of juice, the load av.
> > never shot up over 1.5-2.0.
> > Local/Remote concurrency never shot up, logs showed a max of
> > 2/40 and 6/120.
> >
> > Can anyone explain this? I want qmail to chew/hog the cpu and deliver the
> > mail. What am I forgetting to tune??
> >
> > Thanks
> > Burzin
> >
> >
>
> ---------------------------------
> Timothy L. Mayo mailto:[EMAIL PROTECTED]
> Senior Systems Administrator
> localconnect(sm)
> http://www.localconnect.net/
>
> The National Business Network Inc. http://www.nb.net/
> One Monroeville Center, Suite 850
> Monroeville, PA 15146
> (412) 810-8888 Phone
> (412) 810-8886 Fax
>
Hi there,
Hopefully someone can help me with a problem we're having with
(probably) qmail.
Main system feature is : Solaris 2.6 / Webshield SMTP
As part of the Webshield virus scanner, a version of qmail appears to
have been installed.
We use sendmail as the main connection to the Internet. The qmail system
appears to have a number of messages which can't be delivered, and since
these are multi-megabyte in size, they quickly fill up the 300Mb of free
space we have in the root partition.
The question is, can I delete these messages from the queue directory
structure?
I've tried deleting the files manually, but while I can temporarilly
remove them from the mess/nn subdirectory, they re-appear sometime
later. The only other reference to these files is in the intd directory.
Again I've tried deleting them from there. Even stopping qmail, deleting
the files (they went from both intd and mess subdirs) and restarting
qmail. They're starting to come back ... where else are these damned
messages stored? The fact is they are junk and can be deleted. I suspect
that there is a delivery problem (eg server not responding/not accepting
the messages) so they're not being bounced as undeliverable. There isn't
the disk space available to have qmail timeout these messages gracefully
after the 40 failed attempts.
I've yet to try changing the file message date on the file in the mess
subdirs. Does anyone have any other suggestions. I note from all the
other questions relating to message deletions, that the intd directory
rarely gets a mention. Is this something uniqe to the fact we're running
Webshield?
Thanks for any assistance you can give.
Wallace Nicoll.
--
======================================================================
Wallace Nicoll [EMAIL PROTECTED]
City of Edinburgh Council IT Services,
Chesser House, 500 Gorgie Road, Phone : 0131 469 5343
Edinburgh, EH11 3YJ, Scotland Fax : 0131 469 5335
[From overseas [P]+441314695343 [F]+441314695335 ]
======================================================================
I set up a simple alias something like: [EMAIL PROTECTED] to forward to
[EMAIL PROTECTED] (which pages me) and it just
seems to blackhole. Syslog shows a successful delivery to their smtp
server, I get no bounce message, and they don't respond to any questions
about it.
The only thing I can think of is they filter on the To: header, presumably
as an anti-spam measure. As I intend to be VERY judicious about who gets
this address, I'm not so concerned about spam. Is there a fairly simple
way to modify the outgoing header of an alias to preserve the To: address
of the recipient?
TIA,
On Mon, 11 Oct 1999, [ISO-8859-1] Jon Lur�s wrote:
> Hello!
>
> I have a problem, here is what my qmail log says:
>
> >939620707.238895 status: local 1/10 remote 0/20
> >939620710.595702 delivery 1: success: qmail->
> > inject:_fatal:_read_error/did_1+0+1/
> >939620710.620806 status: local 0/10 remote 0/20
>
> The first time I got this error was with the Vacation program from
> Peter Samuel. The Vacation program uses Datemail. When I
> removed Vacation from the .qmail file and used Datemail directly I
> still got the error. I have tried with Forward in the .qmail and this
> works okay.
>
> I am quite sure that this problem has something to do with
> permissions. I have look at all the permissions in the /var/qmail/bin
> and in the /home/user/Maildir/ with no success so far.
>
> The system is a Redhat 6.0 and I used the
> qmail-1.03-14ucspi.src.rpm for installation.
Just to expand on Jon's problem (we've gone through quite a bit of
offline debugging outside the list). The problem occurs whenever qmail
runs a program from a .qmail file that calls datemail. eg
| vacation jon
or
| /var/qmail/bin/datemail -t < /home/jon/msg
Both of these fail.
Jon, three more things you might try:
1) Double check the permissions on /var/qmail/control/*. ALl the
files in that directory MUST be readable by everyone. If
qmail-inject cannot open /var/qamil/control/me (for example) it
will die. When you did your manual test of datemail what user were
you? If you were root it would have worked, if you were some other
user and it failed, then that could be your problem.
2) modify vacation so that it uses qmail-inject (modify the
Makefile and run make install)
3) recompile datemail
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
Technical Consultant or at present:
eServ. Pty Ltd [EMAIL PROTECTED]
Phone: +61 2 9206 3410 Fax: +61 2 9281 1301
"If you kill all your unhappy customers, you'll only have happy ones left"
I seems to have problem running qmail with supervise. when I start
qmail using supervise, it start off working fine, but after a while it
would
begin to fail. mail are not delivered and preprocessed. restarting
qmail make qmail start deliverying mail again but after a while the
problem would come back again.
I am running qmail 1.03 (compiled from source) with the qmail.init
script contained in the package qmail-run-4.tar.gz. Redhat Linux 6.0
kernel 2.12, SMP, 512Mb ram, and lots of traffic.
any idea what went wrong? any suggstion would be appreciated.
Thanks.
Victor.
Inetd works fine. Nowhere in the FAQ does it say it doesn't. And I got it
to work on my system...eventually.
The problem seems to have been that inetd (or possibly tcpd) is very picky
about spacing when parsing certain command lines. The following (from the
FAQ, BTW) worked fine:
smtp stream tcp nowait qmaild /usr/sbin/tcpd /var/qmail/bin/tcp-env
/var/qmail/bin/qmail-smtpd
For some reason, spacing it with tabs like other lines in inetd.conf
caused it to misbehave. Luckily, that's all finished now, and it's been a
very polite daemon ever since.
Remember today's lesson: perseverence! :)
--
Todd A. Jacobs
Network Systems Engineer
Hi,
I had read a lot of mail to say that HotMail is build by QMail.
But how to implement another HotMail by QMail ?
HotMail have following feature:
1. Several million user
2. Only use domain name for each account (eg: [EMAIL PROTECTED])
3. Multiple mail server to store user mail
My mainly problem is :
1. How to manage such large user account system ?
2. How to dispatch each mail to accurate mail server ?
It is very clearly that we cannot just put user account in different server,
because when we apply the New Accout from Hotmail, HotMail will
check if we choose the already existed username. Besides, when we
mail such as [EMAIL PROTECTED], this mail finally will be dispatch
to such as ms18.hotmail.com, where does Qmail to check this account
should store which mail server ?
Or we should use database or LDAP to centralize all the user account
into one server ? How does it cooperate with Qmail ?
Thanks in advances,
Best Regards,
Farmer Tien
Hi,
What's the best way to kill supervise/tcpserver/qmail processes for
system shutdown? Do the supervise lock directories need clearing up
manually, or what?
I'm on Solaris 5.6, not that it should make any difference ...
Thanks,
Adam.
--
I've been wrong before.
I have a question about MX records. Our users cannot email a certain domain,
say foo.com, and when I looked the domain up, I noticed their entry for mail
exchanger is an IP address rather than a host name. Now I've read somewhere
earlier on the qmail list that this is not correct according to the DNS RFC.
Could someone please confirm this, and also point me to the RFC in question?
Now, the foo.com people says the problem is at _our_ end, and they use the
IP address to reduce the load of the DNS server, just as you can do by browsing
the web using IP numbers rather than host names. To be honest, this does strike
me as a bit odd but then again if they are not violating any "rules" perhaps
they are right? The problem is not that our server can't see their MX record,
is just that what is there (IP number) is not what qmail expects to see (host
name).
What can I do at our end to sort this out? Any advice would be most
apreciated.
Cheers
Fred
ps. foo.com isn't the domain in question, names have been changed to protect
the guilty :-)
