These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for SECURITY: How do I enable SMTP authentication on outgoing mail. on the new forum.
Web Hosting and Cloud Computing Control Panels
Hey Leif,
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:
http://www.virtualmin.com/faq/one-faq?faq_id=1511#33021
--
Check out the forum guidelines!
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
Hi Joe,
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
Regards,
Leif
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
Hi Joe,
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
Regards,
Leif
Hey Leif,
<i>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?</i>
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. ;-)
--
Check out the forum guidelines!
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
Hi Joe,
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
Regards,
Leif
Hey Leif,
<i>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?</i>
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. ;-)
--
Check out the forum guidelines!
Hi,
All these questions is a result of the increasing or should we say exploding amounts of spam mails the past 2-4 month. And we started to receive 2-4 infected mails to most of the users/domains each day.
I have Spamassassin configured rather strict, I have many Header and Body Tests(I think I add a couple each week) so I think Spamassassin is rather ok.
I have now added a MIME header check to take care of all the infected .exe files, I use this Regular expression:
/name=[[^>]]*.(bat|com|exe|dll|vbs)/ REJECT
It looks like it works fine, no more infected .exe files :-)
So now I´m thinkin of adding a few lines to my Postfix main.cf file, but I´m not shure if it´s doing me any good.
I really would appreciate if you could take a quick look and tell me if I should or shouldn´t use them. Or if you have any other suggestions on how to tighten up Postfix and hopefully minimize the amount of spam.
This is the bottom part of main.cf as it looks now:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
And these are the lines I´m thinking of using:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname permit
smtpd_sender_restrictions = permit_sasl_authenticated permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit
smtpd_recipient_restrictions = reject_unauth_pipelining reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
Regards,
Leif
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
Hi Joe,
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
Regards,
Leif
Hey Leif,
<i>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?</i>
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. ;-)
--
Check out the forum guidelines!
Hi,
All these questions is a result of the increasing or should we say exploding amounts of spam mails the past 2-4 month. And we started to receive 2-4 infected mails to most of the users/domains each day.
I have Spamassassin configured rather strict, I have many Header and Body Tests(I think I add a couple each week) so I think Spamassassin is rather ok.
I have now added a MIME header check to take care of all the infected .exe files, I use this Regular expression:
/name=[[^>]]*.(bat|com|exe|dll|vbs)/ REJECT
It looks like it works fine, no more infected .exe files :-)
So now I´m thinkin of adding a few lines to my Postfix main.cf file, but I´m not shure if it´s doing me any good.
I really would appreciate if you could take a quick look and tell me if I should or shouldn´t use them. Or if you have any other suggestions on how to tighten up Postfix and hopefully minimize the amount of spam.
This is the bottom part of main.cf as it looks now:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
And these are the lines I´m thinking of using:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname permit
smtpd_sender_restrictions = permit_sasl_authenticated permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit
smtpd_recipient_restrictions = reject_unauth_pipelining reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
Regards,
Leif
Hey Leif,
Sounds like ClamAV isn't working, if you're having to block .exe to avoid viruses. Have a look at your maillog while sending a message to the box, and see what it says about clam. There's also a test file that you can send that should always be blocked...it just insures that ClamAV is scanning and is able to delete infected files in your current configuration. Just download this file:
http://www.eicar.org/download/eicar.com
And mail it to your server. It's not actually a virus, but every virus scanner will detect it as one, so you might have to go to extra lengths to download it and/or send it, if you have a virus scanner on your PC or on your outgoing mail server. If that proves too difficult, you can do it all locally:
wget http://www.eicar.org/download/eicar.com
cat eicar.com | uuencode eicar.com | mail root -s "Testing"
But you'll need to install the sharutils package first, if you don't already have them (it might be called something else on platforms other than the Red Hat based ones...but whatever it's called, you need the uuencode command).
--
Check out the forum guidelines!
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
Hi Joe,
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
Regards,
Leif
Hey Leif,
<i>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?</i>
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. ;-)
--
Check out the forum guidelines!
Hi,
All these questions is a result of the increasing or should we say exploding amounts of spam mails the past 2-4 month. And we started to receive 2-4 infected mails to most of the users/domains each day.
I have Spamassassin configured rather strict, I have many Header and Body Tests(I think I add a couple each week) so I think Spamassassin is rather ok.
I have now added a MIME header check to take care of all the infected .exe files, I use this Regular expression:
/name=[[^>]]*.(bat|com|exe|dll|vbs)/ REJECT
It looks like it works fine, no more infected .exe files :-)
So now I´m thinkin of adding a few lines to my Postfix main.cf file, but I´m not shure if it´s doing me any good.
I really would appreciate if you could take a quick look and tell me if I should or shouldn´t use them. Or if you have any other suggestions on how to tighten up Postfix and hopefully minimize the amount of spam.
This is the bottom part of main.cf as it looks now:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
And these are the lines I´m thinking of using:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname permit
smtpd_sender_restrictions = permit_sasl_authenticated permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit
smtpd_recipient_restrictions = reject_unauth_pipelining reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
Regards,
Leif
Hey Leif,
Sounds like ClamAV isn't working, if you're having to block .exe to avoid viruses. Have a look at your maillog while sending a message to the box, and see what it says about clam. There's also a test file that you can send that should always be blocked...it just insures that ClamAV is scanning and is able to delete infected files in your current configuration. Just download this file:
http://www.eicar.org/download/eicar.com
And mail it to your server. It's not actually a virus, but every virus scanner will detect it as one, so you might have to go to extra lengths to download it and/or send it, if you have a virus scanner on your PC or on your outgoing mail server. If that proves too difficult, you can do it all locally:
wget http://www.eicar.org/download/eicar.com
cat eicar.com | uuencode eicar.com | mail root -s "Testing"
But you'll need to install the sharutils package first, if you don't already have them (it might be called something else on platforms other than the Red Hat based ones...but whatever it's called, you need the uuencode command).
--
Check out the forum guidelines!
Hi Joe,
I have been suspecting something is wrong with ClamAV for some time now. You can see this in:
http://www.virtualmin.com/forums/message-view?message_id=84388
Please read the whole thread
I installed sharutils, downloaded eicar testvirus, mailed root, and checked my mail and received a "virus" mail. In other words, ClamAV is NOT working as it should, as I have suspected for some time. Here is the maillog:
Feb 3 02:05:37 server postfix/pickup[[30880]]: A0CD91108001: uid=0 from=< root]
Feb 3 02:05:37 server postfix/cleanup[[31448]]: A0CD91108001: message-id=< 20070203010537.A0CD91108001@server.indecta.se]
Feb 3 02:05:37 server postfix/qmgr[[30881]]: A0CD91108001: from=< root@server.indecta.se], size=429, nrcpt=1 (queue active)
Feb 3 02:05:44 server postfix/local[[31449]]: A0CD91108001: to=< server.indecta@server.indecta.se], orig_to=< root], relay=local, delay=7, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
Feb 3 02:05:44 server postfix/qmgr[[30881]]: A0CD91108001: removed
So, any ideas what to do?
And do you have any suggestions about the added options to Postfix main.cf?
Regards,
Leif
BTW-This is not a security issue. Accepting mail addressed to your users is what SMTP is for.
--
Check out the forum guidelines!
Hi Joe,
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
Regards,
Leif
Hey Leif,
<i>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?</i>
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. ;-)
--
Check out the forum guidelines!
Hi,
All these questions is a result of the increasing or should we say exploding amounts of spam mails the past 2-4 month. And we started to receive 2-4 infected mails to most of the users/domains each day.
I have Spamassassin configured rather strict, I have many Header and Body Tests(I think I add a couple each week) so I think Spamassassin is rather ok.
I have now added a MIME header check to take care of all the infected .exe files, I use this Regular expression:
/name=[[^>]]*.(bat|com|exe|dll|vbs)/ REJECT
It looks like it works fine, no more infected .exe files :-)
So now I´m thinkin of adding a few lines to my Postfix main.cf file, but I´m not shure if it´s doing me any good.
I really would appreciate if you could take a quick look and tell me if I should or shouldn´t use them. Or if you have any other suggestions on how to tighten up Postfix and hopefully minimize the amount of spam.
This is the bottom part of main.cf as it looks now:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
And these are the lines I´m thinking of using:
readme_directory = /usr/share/doc/postfix-2.2.2/README_FILES
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname permit
smtpd_sender_restrictions = permit_sasl_authenticated permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain permit
smtpd_recipient_restrictions = reject_unauth_pipelining reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks permit_sasl_authenticated reject_unauth_destination
message_size_limit = 25600000
header_checks = regexp:/etc/postfix/mime_header_checks
Regards,
Leif
Hey Leif,
Sounds like ClamAV isn't working, if you're having to block .exe to avoid viruses. Have a look at your maillog while sending a message to the box, and see what it says about clam. There's also a test file that you can send that should always be blocked...it just insures that ClamAV is scanning and is able to delete infected files in your current configuration. Just download this file:
http://www.eicar.org/download/eicar.com
And mail it to your server. It's not actually a virus, but every virus scanner will detect it as one, so you might have to go to extra lengths to download it and/or send it, if you have a virus scanner on your PC or on your outgoing mail server. If that proves too difficult, you can do it all locally:
wget http://www.eicar.org/download/eicar.com
cat eicar.com | uuencode eicar.com | mail root -s "Testing"
But you'll need to install the sharutils package first, if you don't already have them (it might be called something else on platforms other than the Red Hat based ones...but whatever it's called, you need the uuencode command).
--
Check out the forum guidelines!
Hi Joe,
I have been suspecting something is wrong with ClamAV for some time now. You can see this in:
http://www.virtualmin.com/forums/message-view?message_id=84388
Please read the whole thread
I installed sharutils, downloaded eicar testvirus, mailed root, and checked my mail and received a "virus" mail. In other words, ClamAV is NOT working as it should, as I have suspected for some time. Here is the maillog:
Feb 3 02:05:37 server postfix/pickup[[30880]]: A0CD91108001: uid=0 from=< root]
Feb 3 02:05:37 server postfix/cleanup[[31448]]: A0CD91108001: message-id=< 20070203010537.A0CD91108001@server.indecta.se]
Feb 3 02:05:37 server postfix/qmgr[[30881]]: A0CD91108001: from=< root@server.indecta.se], size=429, nrcpt=1 (queue active)
Feb 3 02:05:44 server postfix/local[[31449]]: A0CD91108001: to=< server.indecta@server.indecta.se], orig_to=< root], relay=local, delay=7, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
Feb 3 02:05:44 server postfix/qmgr[[30881]]: A0CD91108001: removed
So, any ideas what to do?
And do you have any suggestions about the added options to Postfix main.cf?
Regards,
Leif
Hi Joe,
ClamAV is obviously not working!
Where do I start looking for the problem?
Regards,
Leif
Hey Leif,
Ok, ClamAV isn't working. Let's figure out why:
Does clamscan work? cd to the dir where you downloaded eicar.com (or download it now).
# clamscan eicar.com
You should get something like this:
eicar.com: Eicar-Test-Signature FOUND
----------- SCAN SUMMARY -----------
Known viruses: 80498
Engine version: 0.88.7
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Time: 1.435 sec (0 m 1 s)
You may also get a warning about the virus database age, if freshclam isn't running.
If that works, then we'll need to get some logs to find out what's going wrong:
Turn on procmail logging by adding the following to the top of your /etc/procmailrc:
LOGFILE=/var/log/procmail.log
VERBOSE=yes
LOGABSTRACT=all
LOG="Mail is to $LOGNAME "
Then watch /var/log/procmail.log while sending mail to your system. This might turn up something.
If it doesn't...I'll be happy to drop in on the box and troubleshoot it.
--
Check out the forum guidelines!
Hi Joe,
Here is the procmail.log:
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
What does "cli_untgz: Disk quota exceeded" mean???
[[root@server ~]]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda2 73G 5.4G 64G 8% /
/dev/hda1 99M 14M 81M 14% /boot
/dev/shm 252M 0 252M 0% /dev/shm
Hey Leif,
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.
--
Check out the forum guidelines!
Hmmm...
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.
Thanks,
Leif
Hey Leif,
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.
--
Check out the forum guidelines!
Hi Joe,
Now all quotas are correct. And I think I got it right:
All user quotas + Server administrator's quota = Total server quota
I don't think this was the problem though, as I said earlier no quotas was near their limits.
This error:
-----------
LibClamAV Error: Wrote 0 instead of 512 (/tmp/clamav-0801f38e76bc7a23/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
-----------
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"
Regards,
Leif
Hi Joe,
Sorry for being stubborb...
Regarding the authentication when sending mails and using the own server as the outgoing SMTP.
I tried on our old server to send a mail FROM a fake account to an account on the server, with no success.
And yes every one (not using the server as outgoing SMTP) can send mails TO all accounts on the server
If I do the same on our new server the mail gets delivered.
I configured a mail account for the old server with all settings correct, entered the right username but WRONG pwd. With these settings i'm not able to send any mails FROM/WITH our server, neither to accounts outside the server or localy on the server.
This is the way I want our new server to handle the outgoing mail. I now DO KNOW it's working.
On our new server you can put in what ever you like in your mail client information as long as you enter either the server IP or mail.some-domain-on-the-server.tld in the SMTP field. You can now send mails to all users on our server, with our server as the outgoing SMTP in your mail client.
How do I configure our new server to handle the outgoing SMTP the same way that the old server does??? and I now know it can be configured to work that way! :-)
Regards,
Leif
Hi Joe,
Sorry for being stubborb...
Regarding the authentication when sending mails and using the own server as the outgoing SMTP.
I tried on our old server to send a mail FROM a fake account to an account on the server, with no success.
And yes every one (not using the server as outgoing SMTP) can send mails TO all accounts on the server
If I do the same on our new server the mail gets delivered.
I configured a mail account for the old server with all settings correct, entered the right username but WRONG pwd. With these settings i'm not able to send any mails FROM/WITH our server, neither to accounts outside the server or localy on the server.
This is the way I want our new server to handle the outgoing mail. I now DO KNOW it's working.
On our new server you can put in what ever you like in your mail client information as long as you enter either the server IP or mail.some-domain-on-the-server.tld in the SMTP field. You can now send mails to all users on our server, with our server as the outgoing SMTP in your mail client.
How do I configure our new server to handle the outgoing SMTP the same way that the old server does??? and I now know it can be configured to work that way! :-)
Regards,
Leif
Hey Leif,
Being stubborn is fine. I make a habit of it, myself. And despite appearances to the contrary I don't know everything about system administration, though I try. ;-)
BUT, I'd have to see more details about the old server. It could be rejecting based on all sorts of things, but it can't possibly be rejecting for failure to authenticate (because none of the sending SMTP servers on the internet are going to authenticate--it just isn't happening that way). I guarantee that if your old server accepts mail from the outside world (e.g. if I can send mail to it from Virtualmin.com or gmail or whatever), I can also connect directly from here and send mail directly to it for users on that server, and those messages will be delivered. I'm absolutely certain of it...it isn't possible to require SMTP authentication and receive mail from outside servers.
There is no facility in the SMTP protocol that is being widely used (OK, there is SPF, but you probably can't quite safely block on this yet...it's something to consider in spamassassin rules, however) to do otherwise. Your mail server <i>must</i> relay (without authentication) for any mail from the outside world to local users in order to receive mail for your users.
So, let's look at the maillog for that old server and see why the mails are being rejected when you try to hook up your mail client to it--we can add a similar rule to your new server and block that small subset of spammy situations. (Send along the relevant section of the old mail server config, as well. That'll help us analyze what's happening and why.)
See, I'm stubborn, too. And I'm happy to chat with an equally stubborn sort. ;-)
--
Check out the forum guidelines!
Hi Joe,
Sorry for being stubborb...
Regarding the authentication when sending mails and using the own server as the outgoing SMTP.
I tried on our old server to send a mail FROM a fake account to an account on the server, with no success.
And yes every one (not using the server as outgoing SMTP) can send mails TO all accounts on the server
If I do the same on our new server the mail gets delivered.
I configured a mail account for the old server with all settings correct, entered the right username but WRONG pwd. With these settings i'm not able to send any mails FROM/WITH our server, neither to accounts outside the server or localy on the server.
This is the way I want our new server to handle the outgoing mail. I now DO KNOW it's working.
On our new server you can put in what ever you like in your mail client information as long as you enter either the server IP or mail.some-domain-on-the-server.tld in the SMTP field. You can now send mails to all users on our server, with our server as the outgoing SMTP in your mail client.
How do I configure our new server to handle the outgoing SMTP the same way that the old server does??? and I now know it can be configured to work that way! :-)
Regards,
Leif
Hey Leif,
Being stubborn is fine. I make a habit of it, myself. And despite appearances to the contrary I don't know everything about system administration, though I try. ;-)
BUT, I'd have to see more details about the old server. It could be rejecting based on all sorts of things, but it can't possibly be rejecting for failure to authenticate (because none of the sending SMTP servers on the internet are going to authenticate--it just isn't happening that way). I guarantee that if your old server accepts mail from the outside world (e.g. if I can send mail to it from Virtualmin.com or gmail or whatever), I can also connect directly from here and send mail directly to it for users on that server, and those messages will be delivered. I'm absolutely certain of it...it isn't possible to require SMTP authentication and receive mail from outside servers.
There is no facility in the SMTP protocol that is being widely used (OK, there is SPF, but you probably can't quite safely block on this yet...it's something to consider in spamassassin rules, however) to do otherwise. Your mail server <i>must</i> relay (without authentication) for any mail from the outside world to local users in order to receive mail for your users.
So, let's look at the maillog for that old server and see why the mails are being rejected when you try to hook up your mail client to it--we can add a similar rule to your new server and block that small subset of spammy situations. (Send along the relevant section of the old mail server config, as well. That'll help us analyze what's happening and why.)
See, I'm stubborn, too. And I'm happy to chat with an equally stubborn sort. ;-)
--
Check out the forum guidelines!
Hi,
hehe... yes stubborn is good!
So i'm going to send you a mail with some info, and hopefully you will try sending a mail to a local user on that doman.
What do you make of my post #16
Regards,
Leif
Hi,
Just for the record...
Regardin #17 and #18
I was wrong and Joe was right... as always! :-)
Regards,
Leif