postfix issue

this email just disapered from teh queue but still isnt going to the right username…
and these are the logs that appeard when it left the queue

Apr 1 19:43:29 59509 postfix/local[10102]: 54D0B13C667: to=<mbcis@ns4.webtastix.co.nz>, orig_to=<mbcis@mbcis.org>, relay=local, delay=994, delays=0.76/0.01/0/994, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
Apr 1 19:43:37 59509 postfix/local[11294]: 56D9F3E4005: to=<root@ns4.webtastix.co.nz>, orig_to=<root>, relay=local, delay=32, delays=0.19/0.01/0/31, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
Apr 1 19:43:37 59509 postfix/qmgr[10788]: 56D9F3E4005: removed
Apr 1 19:45:22 59509 postfix/pickup[10787]: 46BFE3E4005: uid=0 from=<root>
Apr 1 19:45:22 59509 postfix/cleanup[11387]: 46BFE3E4005: message-id=<20090402024522.46BFE3E4005@ns4.webtastix.co.nz>
Apr 1 19:45:22 59509 postfix/qmgr[10788]: 54D0B13C667: from=<Shane.Langley@chh.co.nz>, size=10890, nrcpt=1 (queue active)
Apr 1 19:45:22 59509 postfix/qmgr[10788]: 54D0B13C667: removed

i turned something off when i first set this up because it wouldnt send anything from the machine out im pretty sure that was chroot but mabye not

Dude, you’re a hazard! If you don’t know what something does…might be best to leave it alone. :wink:

So, the question then becomes, “How did you turn off chroot?” Because those log entries tell me that Postfix is still doing something with the chroot. If the init script is no longer maintaining the chroot, but Postfix is using it, that would cause a lot of trouble. (I’m all for disabling the chroot, if you know how. But mostly we just recommend folks stick with their OS defaults. Everything works if you let it.)

and the email is still sitting in the mail queue even though it says it sent there?

In that case, the mail we saw in the logs was not the one you sent. It was an error from Postfix. The message we saw referenced in the log can’t possibly still be in the queue.

So, where’s the rest of the log entries relating to that message?

well that was the only email log, but then came that second bit whihc i posted just above ^^
i disabled it thru webmin editing the master.cf bit as it told me somewhere (i cant quite remember which website now)
and i had to disable it to let me send email it wouldnt work at all beore that

Hrm, that’s unusual!

I might suggest commenting out the first two lines (which start with "YOUR_IP_ADDRESS:smtp") and then adding this one line:

[code:1]
smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes
[/code:1]

And then restart Postfix:

/etc/init.d/postfix restart

doing that wont take over any of the other ip’s?

doing that wont take over any of the other ip's?

Yes. You got more than one SMTP server?

Alright, lemme read some of the history of the thread here before I make any definite suggestions :slight_smile:

However, in general, the way to control what IP address Postfix listens on is to set inet_interfaces in the main.cf file. And unless you’re really sure of what you’re doing, you’d generally include the localhost interface in all that.

But lemme re-read what all you guys have been doing here :slight_smile:
-Eric

well theres 5 ip address’s and theres one running on another ip address… not postfix or anything like that though and that one runs perfectly

But lemme re-read what all you guys have been doing here

Nothing much. :wink:

i have got the 2 interfaces listed in the main.cf one…

Alright, to sort of play along with your current setup (which is, well, a little odd :-), I think part of the problem may be that Postfix is not listening on the local interface.

Assuming that nothing else on your server is, what you may need to do is add this line to your master.cf:

[code:1]127.0.0.1:«»smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes[/code:1]

And make sure 127.0.0.1 is added to your inet_interfaces line in your main.cf – then restart Postfix.
-Eric

have sent it one, its still setting in the queue at the moment still with the destination address as mbcis@ns4.webtastix.co.nz though? but will see what logs go thru if it ever does anything

also, not sure if this matters but emails are constantly delievering to root successfully for cron jobs

Alright, do you think one of us could just log in and take a look?

Something’s definitely going on that we’re overlooking here in the forums, but it’ll likely stand out a little quicker if we were looking at your system.

If that’s okay, you can send your root login details to:

joe@virtualmin.com
eric@virtualmin.com

Also, be sure to include the following in the message body:

  1. A link to this forum thread

  2. An email address that should work, but isn’t

Thanks,
-Eric

if it was anyone else id say no…but seeing ur helping me then yes :stuck_out_tongue: have sent those :wink:

Cool thanks.

I sent a message to your reply-to address there – I’m holding up on making some changes until I hear back from you on that :slight_smile:

Thanks!
-Eric

have replied…sorry was driving home from work

Okay, after making only a few small tweaks, the main issue I see going on here is a hugely slow ClamAV process.

The system load was fairly huge, and some clamscan processes had been running for several hours.

And every time we sent a test message, it got just a little worse :slight_smile:

So it’s not that it isn’t delivering email. It was just delivering it so slowly, that it just appears as if it isn’t :slight_smile:

There’s some additional information on that problem, and the solution, mentioned in here:

http://www.virtualmin.com/forums/help-home-for-newbies/email-not-being-delivered.html#19259

Essentially, you need to enable the Debian volatile repository, and pull down the clam related packages from it to replace the ones you currently have installed.

Once you do that, I think you’ll notice a pretty big performance difference :slight_smile:

Also, though, you may want to enabling the "Server Scanner (clamdscan)" in Email Messages -> Spam and Virus Scanning for additional performance improvements.

You have a gig of RAM, that should be plenty for the Clam daemon.

Feel free to yell if you have any questions on any of the above.

Have a good one!
-Eric

is there anyway for now that we can just disable clamav? to test if that is the actual problem?

In Edit Virtual Server -> Enabled Features, you can disable Virus Scanning for that domain.
-Eric