I have done some fiddling around with logging in procmailrc and found it may have to do with: â< /dev/nullâ needed for lookup-domain.pl . Variable VIRTUALMIN is never assigned. @staff Is there a way to overcome this error?
It showed that VIRTUALMIN did not get an id assigned.
I have put a shell wrapper around lookup-domain.pl to overcome the use of the redirect of stdin and lo-and-behold now virtualmin idâs are visible for LOGNAMEâs with spanscanning enabled.
Itâs odd that the </dev/null is needed, because the lookup-domain command really does need to take the email as input in order to check the total size and potentially reject the message if the user is over quota.
Unless perhaps in your case the recipient is running out of quota??
The < /dev/null was there already, not added by me.
When I run lookup-domain.pl from the shell it waits for input from stdin and entering Ctl-d or adding < /dev/null is needed.
Feeding the e-mail to lookup-domain.pl seems odd to me for a lookup-domain function (?).
Anyway, are you suggesting I remove < /dev/null ?
PS. No the recipient are not running out of quota.
Is there any logs of the workings of the spam-/hamtrap ? The sa-learn dump does not increment counters of nspam or nham the n I feed junk.
If I execute sa-learn from the shell I can see it incrementing nspam counter.
I looked at it and I think it is not executing it well.
The logs show that sa-learn is considering the address I forward the message from and the recipient : spamtrap@, not the original sender and recipient.
It indicates that the message is learnt as spam but I doubt it means the original message. I als forwarded as attachment but that looks similar.