HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Installation/Configuration (http://www.howtoforge.com/forums/forumdisplay.php?f=27)
-   -   Problem sending mail when not installing amavisd-new (http://www.howtoforge.com/forums/showthread.php?t=48904)

juan_g 19th September 2010 23:44

Problem sending mail when not installing amavisd-new
 
Just a note mentioning an email problem and a solution I've just found, because I think probably other users not installing amavisd-new will be affected by it, maybe without finding the cause.

I'm testing ISPConfig 3 on a VPS. First I tried with Ubuntu, and now with Debian installing everything from scratch, since Debian seems the most supported Linux distribution for ISPConfig. I've followed The Perfect Server - Debian Lenny (Debian 5.0) [ISPConfig 3].

I skipped the step 10 "Install Amavisd-new, SpamAssassin, And Clamav", since I will use ISPConfig to send mail (SMTP), and Google Apps (the free Standard edition for this test site) to receive it. This will save resources on the VPS, letting Google take care of spam and viruses.

However, not installing amavisd-new caused email to be blocked in the mail queue: Monitor -> Logfiles -> Show Mail Queue, with the error "connect to 127.0.0.1[127.0.0.1]:10024: Connection refused".

According to Wikipedia's List of TCP and UDP port numbers, that port (10024) is used for SMTP, to Amavis from Postfix. The solution was in Remove Amavis Content Filter From Postfix Configuration, Requeue All Postfix Email Messages, that is commenting out a few lines of Postfix configuration for Amavis, in the files main.cf and master.cf of the /etc/postfix directory, reloading Postfix, and requeueing blocked messages.

That fixed it, with SMTP working fine now without Amavisd-new, SpamAssassin, and Clamav.

Maybe this solution could be automated in next ISPConfig 3 releases, detecting if amavisd-new is installed or not, and modifying configuration files accordingly.

As a side note, I think it would be helpful to have some brief documentation with examples to configure email clients (Thunderbird, etc.) to work with email accounts created by ISPConfig. I didn't find any mention about this. With a mailbox such as test@example.com, I was trying "test" as user name for the SMTP configuration in Thunderbird. The correct setting, for Thunderbird and SquirrelMail, was "test@example.com" as the user name (this is different for other SMTP servers I'm using). Solving this authentication problem led to be able to solve the other, related to amavisd-new.

till 20th September 2010 11:34

Or you could have taken a look into the ispconfig FAQ:

http://www.faqforge.com/linux/contro...n-ispconfig-3/

juan_g 20th September 2010 14:26

You are right. I'm sorry, I hadn't seen it. The Amavis issue is indeed included in the ISPConfig 3 FAQ as "How to disable spamfilter- and antivirus functions in ISPConfig 3". And it includes additional info, such as another line (receive_override_options = no_address_mappings) that also needs to be commented out when disabling Amavis so that Postfix checks virtual aliases. Thanks!

Another related point I mentioned I'm testing now is how to use ISPConfig to send mail, and Google Apps to receive it (filtering spam, etc.). With this configuration, emails sent between accounts in the same domain weren't being received, naturally because they don't go out of my server to Google. I'm now trying a workaround with a subdomain alias in Google, as described in Emails local delivered with Postfix. But the alias verification is taking time, it seems because of DNS propagation.

juan_g 21st September 2010 03:13

It's working...
 
This configuration is working very well now, including the mentioned workaround, to send mail via ISPConfig and SMTP, and receive it via Google Apps and POP. As said, this prevents loading too much a small VPS with spam filtering, etc.

The alias validation is still in progress, but everything is working already after DNS propagated (the subdomain alias needed its own MX records from Google). Now, for each mail account in Google Apps, there is a forward in ISPConfig to its subdomain alias, to fix the problem with internal mail. In my tests, mail forward worked better than routing for this. I added also an empty mailbox smtp@example.com in ISPConfig, just to configure the SMTP user in mail clients such as Thunderbird. So far, so good.

wahid 12th October 2010 00:01

Hi juan_g, hello Till,

First of all thank you very much juan_g for the above posted link http://www.question-defense.com/2009...email-messages who saved me to retrieve my mails again and specially this part on master.cf:
Quote:

#amavis unix - - - - 2 smtp
# -o smtp_data_done_timeout=1200
# -o smtp_send_xforward_command=yes
After an update from the 3.0.2.2 Version to 3.0.3 of ISPConfig, Postfix was rejecting every sent mail. As with you, I couldn't use amavis or clamav on my hosted VPS, since its resources are not really sufficient.

And for your suggested combination with GoogleApps, I find the idea not bad. But I think, the idea behind to "administer" an own mailserver is to feel free from any third-party solution, even if some features are missing. Talking about my case, I'm using Postfix for personal purpose, therewith avoiding Freemails & Co. and learning progressively to administer this robust mailserver. And fortunately till now it's still running spam-free :)


All times are GMT +2. The time now is 00:00.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.