Hi, I have a recent installed IPSCONFIG3 on centos 6.7 64bits; I followed "the perfect server..." tutorial. Everything is working fine as described in the tutorial; website, dns server, mail server. But... Because there is always a but... In order to perform an advanced spam filtering test, I created 2 dummy mailboxes on a dummy local domain: - sender@my_local_domain.net - destination@my_local_domain.net On a website I found a sample of redirection for cutom rules, put it in custom rules of destination@my_local_domain.net, and modify it in order to send back mail to sender permanently (very simple): redirect "sender@my_local_domain.net"; keep; It does exactly what expected: When sender@my_local_domain.net sends a mail, it's delivered to destination@my_local_domain.net mailbox and a copy is returned to the sender. My mailer deamon is Dovecot with sieve spam filtering syntax. I want to reject spam mail, following sieve documentation I replaced the redirect directive by reject directive + stop like this: reject "this is a permanent reject notification"; stop; But when I apply this rule, nothing happens: The mail isdelivered to destination@my_local_domain.net and no notification is delivered to sender@my_local_domain.net. I made then another test (nonsense but just to be sure that the problem is not the stop line): reject "this is a permanent reject notification"; keep; And same: The mail is delivered to destination@my_local_domain.net, no notification is delivered to sender@my_local_domain.net. It seems that the filter ignore the reject directive. I'm sorry if I disturb with stupid questions (I'm not very skilled with such things, and with ISPCONFIG I'm a complete noob) but is it normal that the reject directive doesn't apply ? Does anybody else experienced this case ? Maybe this rejection cannot work or I made a syntax mistake but I spent a lot of time searching and could not find answer or beginning of solution. Any help or advice will be welcome. Per advance thanks
You can not reject a email with a sieve rule as the email has already been accepted at that point of mail processing. If you like to reject a email then this has to happen in te early stage of mail receiving, you can use a postfix header or body filter for rejects or you can reject with a trsnaport rule.
Dovecot does support rejecting in sieve, but the reject action is not supported by default in the sieve scripts that ispconfig generates. You should still be able to use it though by adding a 'require "reject";' in Custom Rules. Try this (untested): Code: require "reject"; reject "this is a permanent reject notification"; keep; Note that rejecting at this stage should be done very carefully, as a new notification message is created and sent back to the original sender - look up what a "joe job" email is if you're not familiar with it, and make sure your server isn't contributing to those (ie. sending your message notifications to unrelated third parties who the sender claimed to be). Try to use one of the other rejections @till mentioned if you can, to avoid that.
Hi, For the first idea (header checking) I tested with filters in the header_checks file. It works with simple filters like when a matching string or field is found in the mail. However since I'd like to apply different rules depending of the destination mailbox this solution cannot work; The header checks filtering is something very basic and it's a line interpreted filter; means that if 2 conditions to check are on different lines in the header(like "to" field and "subject" field) the line interpreter is not able to combine the logical states of 2 separate tests. I must forget this idea except if I misunderstood the header check process. I made a test with the "require reject;" directive, nothing happened; mail was delivered and no notification, same as described above. Yes, the reject action send notification to sender; I like this action for known and stubborn commercial spammers to which you can send tenth and tenth of unsuscribe notifications with no effect. I understood that the discard action reject too, with no notification. I don't think rejecting with notification contribute to Joe jobing (thanks for learning me this new word, I didn't know there was one to describe this kind of junk mails) since the rejection is explained and detailed in the notification. However in case the sender of a received mail is spoofed, the victim will receive an unexpected reject notification and will then be aware that somebody is using his address for bad purpose. In the reject notification appears usually the original header with originating IP. If I was the spoofed one, for sure I won't be happy to discover it, but I prefer to know it and try to find a solution rather that something continues to happen in my back. I think there are no more choices now for advanced filtering, only the second solution of till remaining.. I'll give feedback about my progress but somethimes it can take a while because it's not my main occupation and I need to study first. So if somebody has done something in this way and accept to share his work, welcome! Thanks to both for contribution.
