How do I enable authentication for outgoing/sending mail with our server?
In the default config/install anyone can connect to our server and send mail to all users/domains on the server.
The smtpd authentication only stops relaying to addresses outside the server.
I want to restrict sending mail with our server to ONLY authenticated users, and I think Postfix has a option called:
smtp_sasl_auth_enable
But I can´t find where and how to configure in Webmin/Virtualmin. If there is no option for this in Webmin/Virtualmin could someone point me in the right direction on how to set this up and enable it.
procmail: [[26836]] Sun Feb 4 03:07:15 2007
procmail: Assigning “LOGABSTRACT=all”
procmail: Assigning "LOG=Mail is to server.indecta "
Mail is to server.indecta procmail: Executing “/etc/webmin/virtual-server/lookup-domain.pl,server.indecta”
procmail: Assigning “VIRTUALMIN=”
procmail: [[26836]] Sun Feb 4 03:07:20 2007
procmail: Executing “/usr/bin/test,115395789926162,!=,”
procmail: [[26836]] Sun Feb 4 03:07:20 2007
procmail: Match on "/usr/bin/test 115395789926162 != "
procmail: Assigning “INCLUDERC=/etc/webmin/virtual-server/procmail/115395789926162”
procmail: Assigning “DROPPRIVS=yes”
procmail: Assuming identity of the recipient, VERBOSE=off
LibClamAV Error: Wrote 0 instead of 512 (/tmp/clamav-71fee4ca0470b156/main.db).
cli_untgz: Disk quota exceeded
LibClamAV Error: cli_cvdload(): Can’t unpack CVD file.
LibClamAV Error: Can’t load /var/lib/clamav/main.cvd: CVD extraction failure
ERROR: CVD extraction failure
From root@server.indecta.se Sun Feb 4 03:07:15 2007
Subject: test
Folder: /etc/webmin/virtual-server/clam-wrapper.pl /usr/bin/clamscan 566
From root@server.indecta.se Sun Feb 4 03:07:15 2007
Subject: test
Folder: /home/indecta/homes/server/Maildir/new/1170554842.26836_0.se 693
So, it looks like there are potentially two problems here.
The first is that your user doesn’t have enough free space within his quota to handle virus scanning. Procmail, when performing all checks and such, becomes the recipient user. Thus, the quotas that apply to your user apply to all processing, as well.
There’s supposed to be a check in place to prevent spam and AV filtering from happening if there is less than 5MB of free quota space for the user…but maybe the requirements for scanning have grown.
First step is to increase the quota of the user, and/or the domain of the user (both the domain and the user must have sufficient free space for scanning to succeed), and test again.
Not proud of it, but I have for example one domain with the total domain quota of 250Mb and I think they have 28 mail accounts of 25Mb each, must be something wrong with my calculator
I’ll look over all domains and do another test after “fixing” the quotas. (I often check the quota usage and I can’t recall no one been over their total domain quota soo far.)
I’ll set all domain quotas higher than the total user quota and try again.
You’re not alone. A lot of folks have been bitten by the “users add up to fill domain” quota issue. It’s a tricky one, and we need better tools for spotting this kind of trouble.
But, there could be other issues…We’ll have to see once the quotas are big enough to contain all of the users in the domain.
seems to hapend only when sending to root, when send to my account this error don’t occur. But there is another error message instead:
procmail: Program failure (1) of “/etc/webmin/virtual-server/clam-wrapper.pl”
When sending the Eicar test virus to root it gets delivered normally and when sending to my account the mail gets droped. To be shure I changed the virus delivery from "Throw away" to "Write to file" and tested again, The Eicar file got delivered to the "virus file" as it should.
I have now removed the MIME header check temporary to see if the infected attachments has gone away or if they start to drop in again.
Is this error ok, or should something be done?
procmail: Program failure (1) of "/etc/webmin/virtual-server/clam-wrapper.pl"
How do you plan to accept mail for your users if you require SMTP auth to relay for them? I suspect you don’t really want to do that–no one (literally no one) will be able to send mail to your users except other users on your server. SMTP is how everyone sends mail to your users–you can’t require authentication for that, unless you only want users to be able to talk amongst themselves.
But, I certainly do suggest SMTP auth for allowing your users to send mail to other servers (otherwise they won’t be allowed to send through your box). SMTP auth is configured by the installer, by default these days, but there’s also a FAQ about it here, if your system was installed before this was setup by default:
Yes I understand that, and SMTP auth works fine so no relaying can be done from unauthenticated users.
So the process of receiving mail is the same as sending mail with the server, I didn’t know that receiving and seding was the same thing.
So I can make an fake account in my mail-client with what-so-ever information besides the SMTP domain, if i there enter mail.somedomain.tld, then I can use this account to send mails to all users connect/handled by that mailserver? Is that right?
What is the difference of these options?
smtp_sasl_auth_enable
smtpd_sasl_auth_enable
Yes I understand that, and SMTP auth works fine so no relaying can be done from unauthenticated users.
So the process of receiving mail is the same as sending mail with the server, I didn’t know that receiving and seding was the same thing.
So I can make an fake account in my mail-client with what-so-ever information besides the SMTP domain, if i there enter mail.somedomain.tld, then I can use this account to send mails to all users connect/handled by that mailserver? Is that right?
What is the difference of these options?
smtp_sasl_auth_enable
smtpd_sasl_auth_enable
Yes I understand that, and SMTP auth works fine so no relaying can be done from unauthenticated users.
So the process of receiving mail is the same as sending mail with the server, I didn’t know that receiving and seding was the same thing.
So I can make an fake account in my mail-client with what-so-ever information besides the SMTP domain, if i there enter mail.somedomain.tld, then I can use this account to send mails to all users connect/handled by that mailserver? Is that right?
What is the difference of these options?
smtp_sasl_auth_enable
smtpd_sasl_auth_enable
Yes I understand that, and SMTP auth works fine so no relaying can be done from unauthenticated users.
So the process of receiving mail is the same as sending mail with the server, I didn’t know that receiving and seding was the same thing.
So I can make an fake account in my mail-client with what-so-ever information besides the SMTP domain, if i there enter mail.somedomain.tld, then I can use this account to send mails to all users connect/handled by that mailserver? Is that right?
What is the difference of these options?
smtp_sasl_auth_enable
smtpd_sasl_auth_enable
So I can make an fake account in my mail-client with what-so-ever information besides the SMTP domain, if i there enter mail.somedomain.tld, then I can use this account to send mails to all users connect/handled by that mailserver? Is that right?
Yep, it’s pretty widely regarded as a mistake…but kinda like democracy, it’s the best idea we’ve got so far.
Mail servers can be configured to authenticate betwixt themselves…but this is only useful in situations where you know which mail servers you’re going to be talking to. This isn’t possible with current mail infrastructure (because there are millions of mail servers out there and they change constantly).
The difference between the options you’ve listed is which side is doing the authenticating. The smtp (client) or smtpd (server) side. So, if you had an upstream MTA at your service provider and needed to route all of your mail through it, you could configure Postfix to authenticate to it. But, realistically, for most users the smtp_sasl_auth_enable option is not useful. That said, as spam filtering gets more aggressive we may find that us “single server” mail users might have to start routing through our hosting providers server in order to get some legitimacy in the eyes of the spam filter heuristics. But, of course, spammers would just route through them, too.
So I can make an fake account in my mail-client with what-so-ever information besides the SMTP domain, if i there enter mail.somedomain.tld, then I can use this account to send mails to all users connect/handled by that mailserver? Is that right?
Yep, it’s pretty widely regarded as a mistake…but kinda like democracy, it’s the best idea we’ve got so far.
Mail servers can be configured to authenticate betwixt themselves…but this is only useful in situations where you know which mail servers you’re going to be talking to. This isn’t possible with current mail infrastructure (because there are millions of mail servers out there and they change constantly).
The difference between the options you’ve listed is which side is doing the authenticating. The smtp (client) or smtpd (server) side. So, if you had an upstream MTA at your service provider and needed to route all of your mail through it, you could configure Postfix to authenticate to it. But, realistically, for most users the smtp_sasl_auth_enable option is not useful. That said, as spam filtering gets more aggressive we may find that us “single server” mail users might have to start routing through our hosting providers server in order to get some legitimacy in the eyes of the spam filter heuristics. But, of course, spammers would just route through them, too.
