Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: bakedjake
This is the same scenario as
after the last debacle, mail was down for a couple of weeks. The support droids were going to reimage the server but somehow managed to fix it without reimaging.
Here's what happened this time.
I did an apt-get install webmin which proceded to upgrade to the latest version. I did apt-get install webmin-mysql and all the other modules that I require.
I also did apt-get install webmin-procmail and procmail filter and this is what I think has screwed up qmail. It asked me a lot of questions such as 'is this an internet server answer 1-5 or x to restart'. I just took the defaults.
Now I have qmail "running" but any mail sent to @mydomain.co.uk is bouncing 550 saying relay not permitted.
ps aux ¦ grep qmail
root 242 0.0 0.2 1948 656? S 10:01 0:00 /usr/bin/tcpserver -H -R 0 pop-3 /usr/sbin/qmail-popup xxx.xxxx
internet.com /var/lib/vpopmail/bin/vchkpw /usr/sbin/qmail-pop3d Maildir
root 599 0.0 0.1 1184 272? S 10:01 0:00 supervise qmail-smtpd
root 601 0.0 0.1 1184 272? S 10:01 0:00 supervise qmail-send
qmaill 603 0.0 0.1 1204 316? S 10:01 0:00 multilog t ./main
qmails 605 0.0 0.1 1236 340? S 10:01 0:00 qmail-send
qmaill 610 0.0 0.1 1196 260? S 10:01 0:00 multilog t ./main
qmaill 611 0.0 0.1 1200 384? S 10:01 0:00 splogger qmail
root 612 0.0 0.1 1200 272? S 10:01 0:00 qmail-lspawn ¦dot-forward .forward?¦preline procmail
qmailr 613 0.0 0.1 1196 268? S 10:01 0:00 qmail-rspawn
qmailq 614 0.0 0.1 1192 292? S 10:01 0:00 qmail-clean
root 3260 0.0 0.1 1284 416 ttyp0 R 10:10 0:00 grep qmail
In the /var/log/qmail-smtpd/current file I got lots of tcpserver: fatal: unable to bind: address already used
But I don't know if they are recent or not because they are not timestamped.
Any ideas? I'm getting little support from the webhosters (again). Their attitude is "you broke it, you fix it"
How have you installed qmail? There might be something wrong with the packages. If you use qmail, you shouldn't have exim installed, in fact you should not be able to install it without removing qmail.
I tracked some dependencies (using "apt-cache show pkgname") and
webmin-procmail requires procmail
procmail recommends exim ¦ mail-transport-agent ¦ fetchmail
If I for example look at the postfix, exim or sendmail package, they have
satisfying procmail's requirement, but I cannot find any qmail related package in stable, testing or unstable that has that. I haven't seen the package generated from qmail-src, but if it hasn't got the above line, that is a problem.
Since Debian has tryed to install exim, it cannot see your qmail installation, and apparently assumes you haven't any mail-transport-agent installed. When you install something that requires an MTA, the default MTA (exim) is installed.
You need to sort out the qmail installation, so Debian is fully aware of what you have installed.
The webhosters said they "locked" it so that webmin wouldnt do it again, but it has!
Qmail was working fine. Haven't reinstalled it or upgraded it.
What I have done now is to remove exim. The problem I have now has changed from a 550 bounce to a "Sorry, no mailbox here by that name. (#5.1.1)"
The mailboxes should be a catch all one, and a postmaster one
e.g. email@example.com and firstname.lastname@example.org
Qmail must be working in the sense that it is receiving mail, but it doesn't know what to do with it. I think Vpopmail is being used to put it in the right queue?
syslog is now showing:
myhost qmail: 1046xxxxx.xxxx inf msg xxxxx: bytes 1535 from <email@example.com> qp xxxxx uid xx
...starting delivery to local firstname.lastname@example.org
....status: local 1/10 remote 0/20
....delivery 12: failure: Sorry, no_mailbox_here_by_that_name._(#5.1.1)/
You must have the original generated qmail package somewhere. If you are sure what configuration changes you have made to it, you could try to reinstall the package with "dpkg -i qmail.deb" or try to purge it completely before reinstalling, with "dpkg -P qmail".
either a) you used the qmail-src debian package which downloads the source, patches it, and compiles + installs it ( unlikely since it installed exim which should confilict with the package qmail-src makes
you download the qmail src and installed it.
But, did you make a fake qmail package? if not, then exim can be installed and muck up your mail.
So, when installing qmail from original sources, you must also make a fake qmail package that provides "qmail". The program to do this is called "equivs" ( apt-get install equivs ). Installing a fake qmail package, will prevent exim from being installed.
as for installing exim, and what it does, i think you should be back to normail if you check inetd that it isn't starting exim, and check
/usr/sbin/sendmail and /usr/lib/sendmail as they should both be symlinks
/usr/sbin/sendmail -> /var/qmail/bin/sendmail
/usr/lib/sendmail -> /var/qmail/bin/sendmail
I don't know if it is true or not. It is what the webhost support guys are telling me.
Anyway, no need to worry about this now. I got so cheesed off with the lack of support from the hosters that I've dumped them.
I still have that duff server working whilst the new server is configured. Mail is arriving but two things happen depending on who the mail is addressed to
1) email@example.com goes straight to the Linux mailbox - I can only read this now by typing MAIL on the console
2) firstname.lastname@example.org (including postmaster etc) fails, but somehow I have managed to get it to forward the fail message and the original message to email@example.com
I got my email client to connect retrieve mail from firstname.lastname@example.org and it works in the sense that I can see mail sent to the site (albeit as a forwarded bounced message).
But as I say, this problem has fixed itself by ditching the webhosters :-)