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
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 fwformail -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
On Thursday 09 June 2016 17:09:56 Gene Heskett wrote:
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 fwformail -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
Found it, so call in the St. Bernards. If I don't start kmail soon enough after the mailwatcher script starts, it fills up the pipeline buffer with sent messages and nothing works until a reboot, which I have now done, so incoming mail is working and pictures are printing. Whoopee!
Now, I have all sorts of pidof -s checks in that bash script where kmail as a process must exist before it will do anything in that "if" stanza, but apparently I need a better test to see if the kmail gui is actually open. This test is apparently saying ok on any piece of kmail that might be running. I might be back to ask about the gui's name later. I might have found a sub, if tdewalletmanager isn't running, then kmail probably isn't ready, so I'm now checking that. And its worked at least once. Goody.
Thanks for puttin up with me folks, it really is appreciated if for no other reason that I am forced to think a little deeper into the problem as I describe the problem to you all.
Cheers, Gene Heskett
On Thursday 09 June 2016 19:26:59 Gene Heskett wrote:
On Thursday 09 June 2016 17:09:56 Gene Heskett wrote:
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 fwformail -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
Found it, so call in the St. Bernards. If I don't start kmail soon enough after the mailwatcher script starts, it fills up the pipeline buffer with sent messages and nothing works until a reboot, which I have now done, so incoming mail is working and pictures are printing. Whoopee!
Now, I have all sorts of pidof -s checks in that bash script where kmail as a process must exist before it will do anything in that "if" stanza, but apparently I need a better test to see if the kmail gui is actually open. This test is apparently saying ok on any piece of kmail that might be running. I might be back to ask about the gui's name later. I might have found a sub, if tdewalletmanager isn't running, then kmail probably isn't ready, so I'm now checking that. And its worked at least once. Goody.
Unfortunately once was it, so I've now plugged in some traceing echo's and got rid of the output to shell silencers. So I am now waiting for the next incoming mail to generate some trace output. Which at the rate traffic is moving tonight, might be the echo from this lists server after I post this.
Thanks for puttin up with me folks, it really is appreciated if for no other reason that I am forced to think a little deeper into the problem as I describe the problem to you all.
Cheers, Gene Heskett
Cheers, Gene Heskett
-
Gene Heskett