[Dovecot] redelivered mail results in mail-forwarding-loop
I try to redeliver mail for the following reason:
Once in a while a user receives a mail which isn't correctly recognised as SPAM/HAM. He'll move the mail into a specific folder (say: retrain-as-spam/retrain-as-ham) and a script will retrain the mail. What I'd like to do is to redeliver the mail in order for correct (re)delivery (e.g. sieve scripts). Using sendmail to redeliver the mail I'm able to re-run the spam tests which will add it's SPAM headers and dovecot/sieve will be able to correctly file the message.
I tried to just resend the mail:
# /usr/sbin/sendmail -f foo@bar -v -oi foo@bar < mail
but this results in a
Diagnostic-Code: X-Postfix; delivery via dovecot: mail forwarding loop for foo@bar
The problem is that the mail already has a "Delivered-To: foo@bar" line.
The above is working when the "Delivered-To" line is being removed, and my question is if this can't be done automatically?
On Mon, Feb 09, 2009 at 09:32:43PM +0100, Reto Glauser wrote:
The above is working when the "Delivered-To" line is being removed, and my question is if this can't be done automatically?
You can avoid generating a Delivered-To header in the first place by removing "D" from the "flags=..." part of the Postfix master.cf entry for Dovecot. This will, of course, disable this loop avoidance mechanism for all messages.
If you don't want this, you'll have to teach the script that reinjects the message to remove the header.
On 02/09/2009 10:06 PM, Ulrich Zehl wrote:
You can avoid generating a Delivered-To header in the first place by removing "D" from the "flags=..." part of the Postfix master.cf entry for Dovecot. This will, of course, disable this loop avoidance mechanism for all messages.
If you don't want this, you'll have to teach the script that reinjects the message to remove the header.
Thanks for elaborating. I discovered "antispam - The dovecot antispam plugin" (http://johannes.sipsolutions.net/files/antispam.html) which actually does what I want to achieve and will give up my initial idea.
I just discovered the antispam plugin (http://johannes.sipsolutions.net/Projects/dovecot-antispam) and set it up successfully. This looks like a really simple an efficient way of handling retraining.
For testing purposes I was moving a (correctly classified) mail from a user's INBOX to the SPAM folder where it was handed over to DSPAM for retraining. I verified the retraining (it has actually being processed 4 time due to the setting "TestConditionalTraining on"), but when verified manually the mail was still classified as "Innocent".
E.g.
# dspam --client --user myuser --mode=notrain --stdout --classify < mail_which_should_now_be_spam X-DSPAM-Result: myuser; result="Innocent"; class="Innocent"; probability=0.0000; confidence=0.51; signature=4991de6d180672059758908
Now, this is something which is happening from time to time and results in similar SPAM getting through several times until DSPAM correctly recognizes the SPAM (even though "TestConditionalTraining" is activated).
My question is the following: Is it possible to first retrain (with --mode=error) and afterwards corpus feeding the mail until it
a) is correctly classified b) has a (configurable) confidence of say 0.8
If a retrained mail gets through a second time the whole process of re-learning and training doesn't make sense in a user's mind and gives the impression that the SPAM setup doesn't quite work (even though the hit rate may be well over 98%).
Thanks, Reto
participants (2)
-
Reto Glauser
-
Ulrich Zehl