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".

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 [email protected], I was trying "test" as user name for the SMTP configuration in Thunderbird. The correct setting, for Thunderbird and SquirrelMail, was "[email protected]" 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.

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.

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 [email protected] in ISPConfig, just to configure the SMTP user in mail clients such as Thunderbird. So far, so good.

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