Two annoying issues when using email are spam and viruses. Fortunately you can fight both using AMaViS (A Mail Virus Scanner). AMaViS is an interface between Postfix, SpamAssassin (famous for its Bayesian spam filtering capabilities) and optionally a virus scanner. AMaViS contains the spam filtering part but has no virus scanner built in. You have installed ClamAV for that purpose. It is a high quality and free virus scanner that gets updated frequently.
The AMaViS configuration is spread across several files in the /etc/amavis/conf.d directory. Fortunately the virus scanner "ClamAV" is already configured by default, though it will need enabling in the file /etc/amavis/conf.d/15-content_filter_mode by removing the '#' from the @bypass_... lines so that spam and virus filtering gets enabled. (It's confusing that enabling the bypass option actually enables spam and virus scanning.)
I suggest you also take a closer look at /etc/amavis/conf.d/20-debian_defaults. Don't change this file though. If you want to change settings then put them into the /etc/amavis/conf.d/50-user file.
- $sa_spam_subject_tag: if this line stays uncommented then every email that AMaViS suspects to be spam get this string inserted into the email's subject. If you do not want to alter the subject you should set "$sa_spam_subject_tag=undef". Users can still find out if AMaViS flagged the email as spam by checking the X-Spam-Status header.
- $sa_tag_level_deflt: spam with a score that is greater or equal to this level will get spam headers added. Debugging is easier if you always add the headers so you should consider setting it to some very low score (e.g. "undef" - which is the lowest possible level - so that headers are always added.
- $sa_tag2_level_deflt: emails with a spam score greater or equal to this level will be marked as spam. Usually this default is reasonable. Lower it if too much spam gets through. Raise it if you get too many regular mails caught as spam.
- $sa_kill_level_deflt: should be set to the same value as $sa_tag2_level_deflt
- $final_spam_destiny: the default D_BOUNCE setting is plain stupid here. The usual approach is to tag email as spam. But if you bounced them you would hit some innocent person because spam mails never contain the correct sender address. Just let the user decide what to do with spam. So it is strongly recommended that you set this to D_PASS.
- $spam_quarantine_to: where to send quarantined spam email to. As spam emails are just tagged and then passed through they should not be quarantined. So the recommended setting here is undef.
- $banned_filename_re: carefully check this list because these patterns tell AMaViS when to bounce an email because it contains data that you do not like to receive in an email
So a sensible "50-user" file would be:
$sa_spam_subject_tag = undef;
$spam_quarantine_to = undef; $sa_tag_level_deflt = undef; $final_spam_destiny = D_PASS; 1; # ensure a defined return
Restart AMaViS if you have made changes to the config files:
$> /etc/init.d/amavis restart
Make sure that AMaViS is listening on TCP port 10024:
$> netstat -nap | grep 10024
You should get this output:
tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 12345/amavisd
If you get such a line then AMaViS is running and waiting for incoming SMTP sessions. Otherwise check your /var/log/mail.log file - perhaps you have made a mistake in the configuration files.
A few words on how AMaViS will be plugged into Postfix. If a person sends you an email from the internet it will be received by Postfix (the smtpd process) on TCP port 25 (SMTP). If Postfix accepts the email it will be forwarded to AMaViS on TCP port 10024 (SMTP). And if AMaViS is happy with the email's contents it will be sent back to Postfix on TCP port 10025 (SMTP). Postfix finally delivers the email to the actual recipient. See the chapter "The Big Picture" for an illustration.
Making Postfix forward emails to AMaViS is done by setting the content_filter setting. Also set the "receive_override_options" setting that will be explained later:
$> postconf -e content_filter=smtp-amavis:[127.0.0.1]:10024 $> postconf -e receive_override_options=no_address_mappings
We need to define the smtp-amavis service first in the /etc/postfix/master.cf. And we also need Postfix to listen on TCP port 10025 for emails that get sent back from AMaViS. So add these sections to your /etc/postfix/master.cf:
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o local_header_rewrite_clients=
Restart Postfix first:
$> postfix reload
Now two settings here deserve an explanation. First the receive_override_options are set to no_address_mappings. This disables all address mappings. Your virtual aliases for example are not considered at first. Then the email is sent to smtp-amavis and in the end returned to the 127.0.0.1:10025 service that sets a lot of options. One of those options is the receive_override_options again. But this time the no_address_mappings setting is left out. So at this stage Postfix finally checks your virtual aliases. Sounds complicated? Well, it has to be done like this or otherwise your aliases would be evaluated twice which leads to mails sent twice. The other options are used to disable checks that Postfix has already done during the first stage.
Note: receive_override_options=no_address_mappings makes Postfix not consider aliases any more. So if you wish to disable AMaViS as a content filter then you must disable this parameter, too!
Another tiny caveat is that the user "clamav" must be a member of the system group "amavis" so that the two services are allowed to talk to each other:
$> adduser clamav amavis $> /etc/init.d/clamav-daemon restart
And another issue to take care of: AMaViS tries to find out whether a certain email is incoming (sent from the internet to your domains) or outgoing (sent from your system to the internet) by looking at the @acl_local_domains setting. You need to tell AMaVis where to check if a certain domain is one of your destination domains. The reason is that you usually don't want to scan your outgoing emails. Imagine that an email is accidentally deemed to be spam and your customer gets warned of your emails. You don't need that.
So edit the /etc/amavis/conf.d/50-user file and before the "1;" enter these lines:
@lookup_sql_dsn = (
['DBI:mysql:database=mailserver;host=127.0.0.1;port=3306',
'mailuser',
'mailuser2009']);
$sql_select_policy = 'SELECT name FROM virtual_domains WHERE CONCAT("@",name) IN (%k)';
The @lookup_sql_dsn defines how AMaVis can access your database. And the $sql_select_policy sets the SQL query that is run when AMaVis wants to determine if the destination domain of the currently scanned email is one of your virtual domains. The %k is a list of strings that AMaVis expects to find. The actual query will look like this:
SELECT name
FROM virtual_domains
WHERE CONCAT("@",name)
IN (
'john@example.com',
'john',
'@example.com',
'@.example.com',
'@.com',
'@.')
This may look a bit weird. But in the end the string '@example.com' is searched for. Restart AMaVis:
$> /etc/init.d/amavis restart
Now try sending an email to john@example.com. If you examine the email headers of that mail you should find lines that got added by AMaVis:
X-Virus-Scanned: Debian amavisd-new at mymailserver X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-9999 required=6.31 tests=[none]
Your users will be able to filter out spam depending on this information. The X-Spam-Status line will be set to "Yes" if the spam score is above the required score ($sa_tag2_level_deflt). The X-Spam-Level line contains a number of "*" that desc the spam score. If your email program looked for a X-Spam-Level: ***** header then it would catch spam with at least a score of 5. A real-life example of caught spam:
X-Spam-Status: Yes, hits=16.0 tagged_above=-9999.0 required=6.31
tests=BAYES_99, FORGED_MUA_OUTLOOK, MSGID_FROM_MTA_ID,
RCVD_IN_BL_SPAMCOP_NET, UNDISC_RECIPS, URIBL_OB_SURBL, WORK_AT_HOME
X-Spam-Level: ***************
X-Spam-Flag: YES
All incoming emails should now be tested for viruses and spam. Try that. SpamAssassin comes with a spam sample containing the GTUBE (Generic Test for Unsolicited Bulk Email) that contains a signature that is supposed to trigger spam filters - just like EICAR.COM for virus scanners. Send John that spam email:
$> sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt
Among other information your /var/log/mail.log will now contain a line being written by AMaViS:
amavis[13001]: (13001-02) Passed SPAM, <...> -> <john@example.com>, ...
So the email was detected as spam and passed through to John. Very well. Finally, fix the permissions of the AMaViS configuration files so that no unauthorized user can read the database password:
$> chmod o= /etc/amavis/conf.d/50-user
65 Comments
no_address_mappings should not be global
Submitted by Anonymous (not verified) on
Hi again,
this regards the use of content_filter and receive_override_options in Postfix's main.cf.
I've had some trouble getting sender_bcc_maps and recipient_bcc_maps working correctly. I use them to automatically store sent and received mails for each user in either a separate account (think username.sent@example.org and username.received@exampel.com with the same credentials as for username@example.org), which I have not yet implemented, or alternatively deliver them to a folder of username@example.org by adding an extension to the address (username+sent-backup@example.org and username+received-backup@example.org) and having Sieve take the appropriate action in a global sieve script:
require ["subaddress", "fileinto", "envelope"]; if envelope :detail "to" "sent-backup" { fileinto "sent-backup"; stop; } if envelope :detail "to" "received-backup" { fileinto "received-backup"; stop; }I've yet to test this properly and discuss it with some colleagues and management of our company but it provides a cheap and effective way to counter an accidental deletion of incoming or sent mail by users. At least as long as they don't go into the backup folders and wreak havoc there.
So much for the backstory :)
It turned out that setting no_address_mappings globally, i.e. in main.cf is too broad a restriction just for preventing AMaViS from enqueueing mails multiple times (once per virtual alias?). I don't know if any other breakage occurs but at the very least the mentioned sender_bcc_maps and recipient_bcc_maps are never considered if no_address_mappings is applied globally.
I try to present a solution here but I am not sure if it is as generic as possible. I am also not sure if I overlooked anything.
Instead of applying this restriction globally and removing it locally at certain strategic points like you do above for the 127.0.0.1:10025 smtpd service, it may be better to apply the restriction only locally at specific points.
This means in particular: no content_filter=smtp-amavis:[127.0.0.1]:10024 and no receive_override_options=no_address_mappings settings in main.cf. instead put them in master.cf (right at the top):
smtp inet n - - - - smtpd -o content_filter=smtp-amavis:[127.0.0.1]:10024 -o receive_override_options=no_address_mappingsThis means that only mail that comes in from the outside, via SMTP (on port 25) is content-filter'd with aliases NOT being considered. The reinjection service for AMaViS stays the same as you specified above. This allows for the use of sender_bcc_maps and recipient_bcc_maps. I don't know if there are any other instances where it is desirable to have address manipulation and expansion to aliases enabled but if it doesn't hurt and AMaViS works correctly, why put in artificial restrictions?
What do you think? Are there any obvious problems with this approach? And now that I've finished writing this I realise I should have posted to the mailing list instead :)
My sources:
http://listi.jpberlin.de/pipermail/postfixbuch-users/2003-November/006262.html (in German but that's not a problem I'm sure :))
http://www.postfix.org/FILTER_README.html#remote_only
Settings in main.cf vs. master.cf
Submitted by Anonymous (not verified) on
Now that's odd, I do not see any difference in putting those options in master.cf or main.cf, because they both apply globally (since you added them to the main smtp entry in master.cf).
I am yet to come to that point, I just wiped my first test-installation, and now I am starting all-over.
With my first try, I was playing around with clamav-milter and spamass-milter, because I thought that approach is superior to using amavis, but I could not make spamass-milter ignore outgoing emails, and that's what amavis does with the above shown setup in this tutorial, so this time I am reverting to amavis again.
Amavis-new settings
Submitted by Anonymous (not verified) on
i heard about using amavis-new as a live filter, so postfix can reject the incoming mail an you have no backscratter problems. Is this possible with this setup and what needs to be changed?
many thanks
Use smtpd_proxy_filter
Submitted by Anonymous (not verified) on
Use smtpd_proxy_filter (realtime) instead of content_filter (store and forward)
Alois
spamass+clamav on incoming emails, and only clamav on outgoing
Submitted by Anonymous (not verified) on
Christoph, you wrote: "AMaViS tries to find out whether a certain email is incoming (sent from the internet to your domains) or outgoing (sent from your system to the internet)"
Looks like, it does not exactly work this way, because all it does, is check if the email is coming from a domain managed by this mailsystem, and it fails, if the spammer is sending you spam with a fake sender-address from one of these domains, which is a typical case (from: <spammer@domain.tld> to: <recipient@domain.tld>), and that means, all emails from such a spammer do not get checked by spamassassin.
I just got a hint on the German Debian forums, which should make my initial approach with using clamav-milter + spamass-milter instead of amavis + clamav + spamassassin work as supposed to, so that only externally incoming mails get checked, by letting the (authorized) clients use submission (on port 587) instead of smtp/ssmtp. That way, you can let it do the general virus & spam checking (as defined in main.cf), and just do virus checking on the submission instance (I think, it may be useful to always let it check for viruses, so even on outgoing emails).
All it needs, is uncommenting the submission line in master.cf, and overriding the desired option for it.
What do you think about that?
AMaViS isn't perfect indeed
Submitted by Christoph Haas on
Thanks for the research. I'm currently testing the spamass-milter on my main mail server and it works very nice (and very likely performing better than AMaViS). It's just that even outgoing emails get scanned which I obviously don't want. Do you have a URL to the forum post you found? The "submission" service is already commented out by default as it seems. I'm curious what to configure in it.
Christoph
Second Instance
Submitted by Anonymous (not verified) on
http://debianforum.de/forum/viewtopic.php?f=8&t=113150&p=717973#p717913
It's all about a second instance for the clients to connect and on which no spam-checking is done. I had no time to test this, but it seems to be the most promising approach (the use of amavis and whitlisting all local domains is pretty much a no-go now).
BTW I really was hoping to meet you on IRC, since your blog comments are not really suitable for discussions, and I have to access to mailinglists (yet). Have a look for "MasterOne" if you pass by on IRC.
Spam / Antivirus scanner
Submitted by Anonymous (not verified) on
Just out of curiosity, whats your opinion about Mailscanner ?
Clemo
...if the spammer is sending
Submitted by Anonymous (not verified) on
...if the spammer is sending you spam with a fake sender-address from one of these domains, which is a typical case (from: <spammer@domain.tld> to: <recipient@domain.tld>), and that means,
SPF + || DKIM ?
Alois
Well...
Submitted by Christoph Haas on
SPF is a matter of taste. It often causes trouble if you foward email so the sending system is not covered by the IP address ranges defined in the SPF entry. I would advise against it nowadays. Although it would cover this case.
DKIM is a much better idea. But the general problem here is that the email could be legit! Imagine that john@example.com wants to send an email to alice@example.com.
Without testing and researching I would say: try DKIM and make sure that your users always use authenticated SMTP so that DKIM doesn't accidentally filter them out.
(I still have a documentation on DKIM, SPF, greylisting and smtpd restrictions in the queue. I'm so lazy. But I intend to finish it one day.)
any pointers on SPF ??
Submitted by Anonymous (not verified) on
i have implemented domainkeys via avamis-new but yahoo is still blocking me.
my email is mjh55_98@yahoo.com.
Any chance your documentation
Submitted by Anonymous (not verified) on
Generally marking outgoing emails as No-Spam
Submitted by Anonymous (not verified) on
I may be wrong, but I think GMX is doing this with their own mailings.
Can this be done with spamassasin / spamass-milter in this setup?
The idea is, that maybe the remote mailserver on the recipient-side does not perform spam-checking (or the recipient has not enabled it), but the recipient's email-cient nevertheless recognizes and acts on the X-Spam header, so why not just mark all outgoing emails as "clean"?
don't quarantine spam
Submitted by Anonymous (not verified) on
Since you set
$final_spam_destiny = D_PASS;
you should consider setting
$spam_quarantine_to = undef;
as well. I think there is no point in quarantining spam that has been passed to the user.
At least in my case it just caused to generate a lot of logcheck complaints about quarantined mails (which had actually been delivered), which made it harder to maintain the quarantine directory.
Spam Headers in the email
Submitted by Anonymous (not verified) on
DO NOT FORGET THIS:
... So edit the /etc/amavis/conf.d/50-user file and before the "1;" enter these lines:
@lookup_sql_dsn = ( ['DBI:mysql:database=mailserver;host=127.0.0.1;port=3306', 'mailuser', 'mailuser2009']); $sql_select_policy = 'SELECT name FROM virtual_domains WHERE CONCAT("@",name) IN (%k)';...
I took me hours to have the headers in the Mail ...
So?
Submitted by Christoph Haas on
Erm, isn't the tutorial telling exactly that? :)
local domain check does not work
Submitted by Anonymous (not verified) on
Hello,
the check for whether a domain is local or not does not work.
Amavis is searching for the recipient address, whose domain part is obviously not in the virtual_domains table. One might think that amavis concludes that the sender must be local then, but instead it scans the mail anyway.
Any solutions found? I could image to update a hash table for @local_domains_maps via cron once a day or so, but I would prefer a solution where amavis fetchs the data directly from the sql table.
Regards
Christoph Kling
Remote host said: 530 5.7.0 Must issue a STARTTLS command first
Submitted by Anonymous (not verified) on
hmh, great tutorial here, but I have one issue: When trying to send mail to my server, I get the following errormessage back: "Connected_to Xxx.xxx.xxx.xxx_but_sender_was_rejected./Remote_host_said:_530_5.7.0 Must_issue_a_STARTTLS_command_first/ " My mail.log says the following: "Feb 8 15:35:54 km32901-05 postfix/smtpd[5859]: connect from mail.gmx.net[213.165.64.20] Feb 8 15:35:54 km32901-05 postfix/smtpd[5859]: disconnect from mail.gmx.net[213.165.64.20] " Any advice how to check back on this appreciated. thx!
Restrictions problem?
Submitted by Christoph Haas on
Sounds like a problem in the order of your smtpd_*_restrictions. Please post your configuration to the mailing list for further advice.
spam passed CLEAN
Submitted by Anonymous (not verified) on
I had some problems with the spam-detection.
The email with sample-spam.txt passed through (passed CLEAN).
But I found the solution:
You have to edit /usr/share/amavis/conf.g/20-package and change both values to (0).
After that: /etc/init.d/amavis restart
Maybe it could help someone.
Julian
thanks, but here's the next problem ^^
Submitted by Anonymous (not verified) on
Hi guys,
my first Problem was the same as this one above. I solved it with your suggestion, thanks for it.
But of course the next problem is already waiting... ^^
Now my SpamAssassin detects the GTUBE-TestMail and forward it to the destination MailAccount, because I want him to do it. But the "***SPAM***" marking in the Mail-Subject iss missing. And there are no "X-Spam-*"-Enties in the Mail-Header, too. I thing the Problem is the Write-Right from SpamAssassin for the eMail-Content.
Maybe someone solved the same problem? Or any suggestions?
Thanks for all help, Nils
P.S. Great tutorial ;P
ok solved it myself
Submitted by Anonymous (not verified) on
ok i solved this problem myself now,
in a little look at my cfgs i saw, that i had commented out the mysql-query-part of the /etc/amavis/conf.d/50-user file. after activating this part the problem disappeared. Now my SpamAssassin is working great! :D
anyhow thanks for your work guys ;D
Nils
hi, i want to use
Submitted by Anonymous (not verified) on
hi,
i want to use spamass.., how to configure it?
/touhid
SpamAssassin is used by
Submitted by Christoph Haas on
SpamAssassin is used by AMaViS. So if you run AMaViS you automatically get Spamassassin's scanning feature.
unrar
Submitted by Anonymous (not verified) on
First, thanks a lot for this amazing how-to!
I've noticed this line in syslog:
No decoder for .rar
By default it is disabled in /etc/amavis/conf.d/01-debian
You can enable it in /etc/amavis/conf.d/50-user with $unrar = ['rar', 'unrar'];
You can do the same for any other non-free decoders.
Happy email scanning!
- LC
no support for rar
Submitted by Anonymous (not verified) on
Besides adding the setting you shoul also install unrar-free
Outdated
Submitted by Anonymous (not verified) on
I would advise against running amavis for a number of reasons:
- Outdated, not maintained or updated for a long time
- Memory usage (40~50MB extra)
- CPU Usage
Nowadays with clam-smtpd and spamassasin working together with postfix it isn't needed anymore either.
Hear, hear…
Submitted by Christoph Haas on
You are so right. I don't use AMaViS myself any more for that reason. Currently I have clamav-milter running to scan for viruses and let the users do the spam detection (bayes-based mainly) themselves. The configuration (e.g. per-user spam filters) is nasty and it's slow like hell. 1-2 emails per second with AMaVis and 50 without was my experience.
I hesitated to advise against AMaViS but I think it's worth giving the readers an alternative. I evaluated dspam which was even less maintained and more cryptic. And after I while I think I can claim that there are no decent content filters that I would like to support or recommend.
alternative how-to for clamav-milter+postfix?
Submitted by Anonymous (not verified) on
Can you please point me to a such a nice how-to for clamav-milter+spamass-milter+postfix?
thanks
clamav-milter
Submitted by Christoph Haas on
Actually it's rather simple. Just install the "clamav-milter" package and follow the /usr/share/doc/clamav-milter/README.Debian.gz documentation. Look out for the "POSTFIX" section. For simplicity I suggest not using a UNIX socket with all the complex permissions setup but rather a TCP socket on 127.0.0.1.
Installing Clamav-milter
Submitted by bspark (not verified) on
Client rejected
Submitted by Anonymous (not verified) on
Hey Christian!
Erstmal danke für das großartige Tutorial.
Im Gegensatz zu vielen anderen 'copy&paste' tutorials hast du dir die Mühe gemacht, das ganze auch verständlich zu erklären, sodass man auch weiß, was man da eigentlich gerade editiert.
But there is still a problem I can't really work out.
Everything worked fine, until I worked on this page of the tutorial.
The main problem is, that my Server (in fact it is a vServer) is trying to connect to the services with the external IP rather than on localhost basis.
Amavis gave me a 'access denied' since it didn't know how to handle the external Server IP. But I could fix that by adding a @inet_acl entry.
But still, postfix is not accepting connections from my external IP anymore, so the Mail.log reads like this:
Mar 11 23:29:06 vs5513 postfix/qmgr[1327]: 89FBD7E33: from=<root@vs5513.myserver.de>, size=931, nrcpt=1 (queue active)
Mar 11 23:29:06 vs5513 postfix/qmgr[1327]: 03C047E36: from=<root@vs5513.myserver.de>, size=931, nrcpt=1 (queue active)
Mar 11 23:29:06 vs5513 postfix/smtpd[1358]: connect from vs5513.myserver.de[77.77.77.77]
Mar 11 23:29:06 vs5513 postfix/smtpd[1358]: NOQUEUE: reject: CONNECT from vs5513.myserver.de[77.77.77.77]: 554 5.7.1 <vs5513.myserver.de[77.77.77.77]>: Client host rejected: Access denied; proto=SMTP
Mar 11 23:29:06 vs5513 amavis[22076]: (22076-06) (!)FWD via SMTP: <root@vs5513.myserver.de> -> <john@example.com>, 451 4.5.0 From MTA([127.0.0.1]:10025) during fwd-connect (Negative greeting: 554 5.7.1 <vs5513.myserver.de[77.77.77.77]>: Client host rejected: Access denied at (eval 84) line 555.): id=22076-06
Mar 11 23:29:06 vs5513 amavis[22076]: (22076-06) Blocked MTA-BLOCKED, <root@vs5513.myserver.de> -> <john@example.com>, Message-ID: <GTUBE1.1010101@example.net>, mail_id: aOIKzAQ4oeMP, Hits: 1005.319, size: 931, 162 ms
Mar 11 23:29:06 vs5513 postfix/smtpd[1358]: disconnect from vs5513.myserver.de[77.77.77.77]
The external IP is added in the main.cf under my_networks.
I also tried to 'whitelist' the IP by adding a check_client_access but no dice.
So, if you know how to workaround this bit, I'd really appreciate it!
Regards,
Nick
smtpd_*_restrictions?
Submitted by Anonymous (not verified) on
Hi, Nick...
sounds like your smtpd_*_restrictions could be b0rked. Please post to the workaround-chitchat mailing list for help.
Best regards
Not Christian :)
Spamassassin usersettings for webmail (Roundcube)
Submitted by Anonymous (not verified) on
Hello,
sorry my bad english. This tutorial is creat! but i have questions from Spamassassin (Amavis).
Sorry, ich schreibe so schlecht Englisch, dass ich mein Kommentar lieber in Deutsch schreibe. Ich hoffe, das geht in Ordnung.
Wie angetönt, gemäss diesem Tutorial kriegte ich alles prima zum laufen. Nun fehlt mir noch ein kleines Detail. Ich verwende Roundcube (ich weiss....) dafür gibt es ein schönes Modul (sauserprefs) um usereigene Einstellungen für Spamassassin zu machen. Etwas ähnliches gibt es glaub auch für Squirrelmail. Für sauserprefs geht man davon aus, dass Spamassassin die Konfiguration in eine Datenbank schreibt. Nun habe ich glaub nur die Hälfte kapiert. Gemäss diesem Tutorial hier, scheint mir, dass zwar AMavis mit der DB "mailserver" arbeitet. Aber Spamassassin nicht wirklich. Ich habe gemäss dem Spamassassin-Wiki die entsprechende Tabellen angelegt und das Roundcube-Modul kann seine Settings auch darin speichern. Aber die Einstellungen greifen nicht ;-)
Die Konfiguration von Spamassassin und Amavis habe ich anscheinend noch nicht ganz verstanden. Vielleich hat wer verstanden, was ich ereichen möchte und kann mir ev. weiterhelfen?
Ich würde mich auch schon zufrieden geben, wenn ich wüsste, wo die Black- und Whitelist zu definieren wäre, muss ja nicht unbedingt über die sexy-Weboberfläche sein ;-)
Für Tipps, würde ich mich sehr freuen.
Grüsse,
Fabian
DKIM inside Amavis with DK-Filter
Submitted by Anonymous (not verified) on
I found this guide to use Amavis to sign and test DKIM in incomming mails.
http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim
For those who don't know, DKIM is the successor to Domainkeys and has replaced it.
Google and Yahoo is still sending mails with both DKIM and Domainkeys.
Amavis does not support Domainkeys directly
.
/Thomas
clamd outdated
Submitted by Anonymous (not verified) on
The clamd package in lenny is outdated, a more recent version is avaliable in the volatile repository.
echo "deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free" >> /etc/apt/sources.list
apt-get update
apt-get install clamav clamav-daemon clamav-freshclam
clamd --version #Should be atleast 0.95
/etc/init.d/amavis restart
#Remember to disable volatile apt source again, and run apt-get update
DBI.pm not found on fresh Debian install
Submitted by Anonymous (not verified) on
Depending on how did you go about installing your server, there is a chance that Amavis will spit this out after updating its config to check for the user:
Starting amavisd: Problem in Amavis SQL base code: Can't locate DBI.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl) at (eval 86) line 18. BEGIN failed--compilation aborted at (eval 86) line 18. (failed).This is because DBI.pm is not installed. Luckily, the solution is very simple:
apt-get install libdbi-perlProblem solved.
additional it is recommed to
Submitted by Anonymous (not verified) on
additional it is recommed to execute:
when using postgresql you
Submitted by Anonymous (not verified) on
when using postgresql you might want to install the libdbd-pg-perl package instead:
Amavis with Spamassassin
Submitted by Anonymous (not verified) on
First off, thank you for the great work with this tutorial! I have gone through the entire tutorial and
everything seems to work. Instead of installing squirrelmail I chose to install Roundcube as I have read a lot
of positive reviews about it. After installing I found the plugins and have attempted to install a few of them,
namely the sauserprefs plugin to allow a user to configure their spam assassin settings. Now I find myself
going back through the tutorial a second time to understand how everything works now that I can watch
it in action through the logs, and I guess my questions all seem to be about spam assassin and amavis, and
whether they are combined into one or are they two separate tools. In installing the plugin I mentioned
previously, the config file asked for a database, table, username and password. As I never officially installed
spam assassin, but rather amavis, I am wondering if maybe the plugin is not able to be used for this purpose.
If anyone has any clarity you can bring to my thoughts please repond.
Correction
Submitted by Anonymous (not verified) on
Sorry I should have looked a little further. I see where spam assassin is in the instructions to install,
so therefore I installed it. Now I believe my question is more pertaining to the plugin and how to configure
it since I don't have a spam assassin database/user/password. Unless someone has thoughts about this, I will
just post a comment over at the forum for that plugin.
Getting SPAM tag with all mail
Submitted by Anonymous (not verified) on
Dear,
From last few months all of my email subjects are getting ***SPAM*** tag,
even i sent a blank test mail. What can i do.. Please help me out.
/touhid
Spamassasin userpref
Submitted by Anonymous (not verified) on
Thankyou for this great documentation. Everything is working as it should on my test setup however i am trying to get spamassin working with mysql. The DB and tables are setup, i configured local.cf as below and in debug mode i see that spamassassin can access the tables.
user_scores_dsn DBI:mysql:logs:localhost:3306 user_scores_sql_password password user_scores_sql_username username user_scores_sql_custom_query SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username = '$GLOBAL' OR username = CONCAT('%',_DOMAIN_) ORDER BY username ASCHowever either amavis or spamassasin is ignoring this, the per use settings have no effect.
Any idea what im missing ?
Getting ***SPAM*** tag with mails subject
Submitted by Anonymous (not verified) on
All of the emails sending from my server are getting ***SPAM*** tag in subject,
even when i send a blank test mail. What can i do.. Please help me out.
/SM Touhid
Messages from authenticated users are still flagged as SPAM
Submitted by Anonymous (not verified) on
Ok, I followed the tutorial from the beginig to the end and after some trial and error I managed to setup the mail server corectly.
By the way: I think there is an error in /etc/amavis/conf.d/50-user
Why?
- Messages sent by me to me get flagged as spam and it should be like that.
- Messages that goes out from my network shoul be scanned by AV
I am pressed by time to finish the server and to put in production, so I'll disable spam checking until furter investigation.
I'll be greatfull if You could double check the tutorial about that pearl sql from amavis rules, to enlight us, please.
Thank You
Light Vision
BYPASS AMAVIS for a local network or a specified account
Submitted by Anonymous (not verified) on
The problem of out going e-mails scanned by amavis is that it slows a lot the traffic and it takes for hours to send 500 e-mails (to my customers not spams!) even if you use this confirguration:
@lookup_sql_dsn = ( ['DBI:mysql:database=mailserver;host=127.0.0.1;port=3306', 'mailuser', 'mailuser2009']); $sql_select_policy = 'SELECT name FROM virtual_domains WHERE CONCAT("@",name) IN (%k)';This tells amavis that the email is fine but it still processes it and therefore it is very, very long...
Do you have a solution to bypass amavis when sending e-mails from the local network, a specified network or just a certain e-mail address?
Your help is welcome :=)
Thank you
Patrice
Help?
Submitted by Anonymous (not verified) on
Nobody can help me with the above problem?
Thnak you
Patrice
Is the domain you are sending
Submitted by Christoph Haas on
Is the domain you are sending from (...@domain) listed in your virtual_domains?
Yes otherwise I would not be
Submitted by Anonymous (not verified) on
Yes otherwise I would not be able to send e-mail
Thank you for your answer
Patrice
I'm still looking for a solution, right now I have to disable amavis everytime I want to send a news letter! Not convenient
RE: BYPASS AMAVIS for a local network or a specified account
Submitted by Anonymous (not verified) on
You can look into setting up a separate port (in master.cf) to skip 'content_filter' and other options. This will require changing the port on the clients intended to send out "without scanning". Also, you can use virtual IP, and then use the 'new' IP address.
Make sure you secure your server in a way that no 'intruder' will be able to use this new setup.
Christoph Haas: Thank you for your amazing work!
Pages