On Thursday 09 June 2016 16:51:13 Gene Heskett wrote:

> Greetings all;
>
> fetchmail's log shows it was pulled from both email servers I used.
> Handed off to procmail for delivery, it apparently was
> silently /dev/nulled by procmail.
>
> The only size limits in .procmailrc have to do with taking a maximum
> hit on spamassassin's kids.
>
> In the order in which its executed, this is the catcher recipe, which
> has worked for quite a bit of a decade now, and worked a couple days
> ago for
>
> a smaller picture:
> :0
>
> *.*lrcrispy\@frontiernet\.net
> /var/spool/mail/gene
>
> And the only size limits are below that where it calls the spam 
checking:
> :0
>
> * ^X-Spam-Status:
> {
>
>     :0 fw
>     :
>     | formail -R "X-Spam-Status:" "X-False-Spam-Status:"
>     |
>     :0 fw
>     :
>     | formail -A "X-Nasty: Aren't we?"
>
> }
>
> :0
>
> * ^X-Spam-Level:
> {
>
>     :0 fw
>     :
>     | formail -R "X-Spam-Level" "X-False-Spam-Level"
>
> }
>
> :0
>
> * ^X-Spam-Checker-Version:
> {
>
>     :0 fw
>
> formail -R "X-Spam-Checker-Version:" "X-False-Spam-Checker-Version:"
> }
>
>
> ######################################################################
>######## # Rewrite Reply-To: for SpamAssassin users list
> ######################################################################
>########
>
> :0
>
> * < 500000
> * !^List-Id: .*(spamassassin\.apache.\org)
> {
>
>   :0 fw: spamassassin.lock
>   :
>   | /usr/bin/spamc -t 140 -u gene -d 127.0.0.1
>
> }
>
> # Sometimes SpamAssassin fails to run. This forces the issue.
>
> :0 w
>
> * !^X-Spam-Checker-Version:
> * < 500000
> * !^List-Id: .*(spamassassin\.apache\.org)
> * !^From: .FETCHMAIL-DAEMON@
> {
>
>     :0 fw: spamassassinFailed.lock
>     :
>        | nice -n 1 /usr/bin/spamassassin
>
> }
>
> I am thinking I need a catcher below all his that puts anything that
> still exists in /var/spool/mail/gene so I can manually dispose of it?
>
> Is that how the rest of you are thinking, that there is no save option
> if it falls all the way thru to the last recipe above?  It gets handed
> off to procmail as the MTA, and procmail normally logs the size, but
> there's nothing in that size category in the procmail.log. Leading me
> to think it fell all the way thru for some unk reason.
>
> Comments plz.
>
> Cheers, Gene Heskett

And I may have found it, dbus was restarted by the geoip update this 
morning, and I believe a qdbus update was put in yesterday, so the 
restart brought in the new version, and the SOB is doing a dev/null 
function now. When in a previous email I was showing how dbus wasn't 
finding the kde.org.kmail linkage, I was running the new version, but 
the old one at that point was still in memory being used by my 
mailwatcher script that makes all this crap automatic, so it was still 
working up until I let synaptic restart it.

I'll let some of the smoke clear & hit the debian list about it, say in a 
hour because I've got to print the pix that were in that email, my 
wife's older sisters headstone was set this morning so her daughter took 
some pix.

IOW, not your problem.  Sorry for the noise.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>