Killfiling, anyone?
Guys, what are you using for killfiling/mail filtering? I am using Mutt's built in POP and SMTP at this point, is there any way to killfile emails based on header contents? Scoring won't be enough, I want to delete this crap as the email is being downloaded from my mail provider. I am not looking for bayesian or other high-falutin' anti spam measures. I want to create my own killfile like I do with my newsreader, basically just creating rules that match the idiots that spam the mailing lists I'm in. -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachmentsCode Blue or Go Home!
Re: Thank you for Mutt
On Tue, Jul 24, 2012 at 06:29:33PM +0100, Joe McCool wrote: > On Tue, Jul 24, 2012 at 6:19 PM, wrote: > > > > > Thanks to all the Mutt developers, contributors, and user > > > community. Mutt is a great app! It doesn't suck at all. > > > > > Joining in! Really, Mutt is absolutely the best email client and > > computer is not needed ???. Big thanks to all developers! > I'll second that and third it, if need be :-) As will I. :-) (yeah, I know, but in this case, I think "ME TOO" actually is a valid post .) Later. --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 < Running Mac OS X Lion > spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W Do not look into waveguide with remaining eye! Android Apps Listing at http://www.jstrack.org/barcodes.html
Re: Thank you for Mutt
On Wed, Jul 25, 2012 at 04:17:59AM -0500, Jim Graham wrote: > As will I. :-) Forgot one thing: I've been using Mutt since right around the time it went from alpha to beta status, ca 1995, I think, and have never had even the slightest regret. It has, simply, always been the best for me. On one list I'm on (the Chile-Heads list, fwiw), from time to time the topic of replying to the list will come up, and the fact that most have to do a reply-all to reply to the list, and the resulting duplicate copy that some people get gets people irritated. I sometimes just respond suggesting that they just configure their e-mail program to recognize the list and to use a list-reply. Too bad their e-mail clients just can't do that. Oh well, mine can ;-} Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | "> There it was, right in the title bar: spooky1...@gmail.com | > Microsoft Operations POS." < Running Mac OS X Lion > | ICBM / Hurricane: | "Never before has a TLA been so appropriately 30.44406N 86.59909W| mis-parsed." (alt.sysadmin.recovery) Android Apps Listing at http://www.jstrack.org/barcodes.html
Re: Thank you for Mutt
On Wed, Jul 25, 2012 at 01:00:28AM +0200, Andre Kl?rner wrote: > Well, what do you mean with that? I also noticed that sometimes the > fullscreen running mutt looks a bit unusual when you use 80 of your 250 > columns. But how would you think could one make it better? I'm not sure what you're describing, but if I use an xterm wider than 80 columns, Mutt quite happily expands its UI, and when someone posts long URLs, they don't wrap unless they're longer than my xterm is wide. If you're talking about people posting with a line width of < 80 cols, that's a courtesy to people (like me) who normally read e-mail in an 80 column window. > > No ability to change signatures when changing accounts automatically. > > You can. In fact I am doing it. You can certainly do this. I could do so, if I made a simple modification to my ~/bin/sigset, which is called from ~/.muttrc for setting the .signature every time I start Mutt. (Oh, and I'd like to see people on other e-mail clients try to do THAT!) Of course, most people on those other e-mail clients don't even know how to quote properly, so it'd be difficult to expect them to even begin to try setting up random sigs. Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 < Running Mac OS X Lion > spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W Do not look into waveguide with remaining eye! Android Apps Listing at http://www.jstrack.org/barcodes.html
Re: Thank you for Mutt
On Wed, Jul 25, 2012 at 11:11:03AM +1000, Cameron Simpson wrote: > On 24Jul2012 15:20, Aaron Toponce wrote: > | - No ability to change signatures when changing accounts automatically. > > Well, mutt doesn't have "accounts". It has individual settings for a > bunch of things, which would normally be grouped together as an > "account" in other clients. Mutt is more flexible as a consequence but > also more fiddly. I'd assumed that "accounts" here meant different accounts on different computers. And changing the settings would be as simple as the way I set random sigs, except instead of a random number determining the sig, it would be set based on the host name. > Sattinger's Second Law: Even though you've plugged it in, it still > won't work until you switch it on. That's still not complete, though. I once saw a post in alt.sysadmin.recovery (the thread was something like, "things that make you say umm") where someone told a story about a woman who called tech support, asking why her modem wasn't working. The guy telling the story said he asked her to see if there were any lights lit up on the modem. She said she'd go check. After about 15 minutes, she came back to the phone and said no. So he asked her to check and see if the modem was turned on, and just before he was able to ask why it took her so long, she'd already gone to check. Anyways, she finally gets back, and says yes, it's plugged in. So he then asks why it's taking her so long to get to the modem and back. She responds, saying that the power is out in their building, and their phone system isn't working, so she's having to use a pay-phone across the street. I have that archived somehwere here, if anyone wants me to post a copy, put it online, etc. Just remember, put your coffee down before you read it or C|N>K will be the result (that's another one from ASR---coffee, piped through the nose, onto the keyboard). Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | Peter da Silva: No, try "rm -rf /" spooky1...@gmail.com | Dave Aronson:As your life flashes before < Running Mac OS X Lion > | your eyes, in the unit of time known as an ICBM / Hurricane: | ohnosecond (alt.sysadmin.recovery) 30.44406N 86. 59909W | Android Apps Listing at http://www.jstrack.org/barcodes.html
Re: Killfiling, anyone?
On Wed, Jul 25, 2012 at 08:48:08AM +, John Long wrote: > Guys, what are you using for killfiling/mail filtering? procmail. There's no substitute, IMHO. Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | Peter da Silva: No, try "rm -rf /" spooky1...@gmail.com | Dave Aronson:As your life flashes before < Running Mac OS X Lion > | your eyes, in the unit of time known as an ICBM / Hurricane: | ohnosecond (alt.sysadmin.recovery) 30.44406N 86. 59909W | Android Apps Listing at http://www.jstrack.org/barcodes.html
Re: Killfiling, anyone?
* John Long schrieb am 25.07.2012 um 8:48 Uhr: > Guys, what are you using for killfiling/mail filtering? Procmail http://www.procmail.org/ http://www.ii.com/internet/robots/procmail/qs/ Andreas
Re: Killfiling, anyone?
>From the Debian FAQ:
muttrc:
macro index"|grep "^^From:" | sed -e 's/ *(.*)//; s/>.*//;
s/.*[:<] *//' \
>> $HOME/.spam && echo Add sender to killfile\n" "kill sender"
macro pager"|grep "^^From:" | sed -e 's/ *(.*)//; s/>.*//;
s/.*[:<] *//' \
>> $HOME/.spam && echo Add sender to killfile\n" "kill sender"
procmailrc:
FROM=`formail -xFrom: | sed -e 's/ *(.*)//; s/>.*//; s/.*[:<] *//'`
:0
* ? fgrep -qxis "$FROM" $HOME/.spam
{
LOG="Spam from $FROM"
:0:
spam
}
--
Ivo Engelhardt
Re: Killfiling, anyone?
That's three votes for procmail. I guess I will have to look into it! Thanks everybody. -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachmentsCode Blue or Go Home!
Re: Thank you for Mutt
On Wed, Jul 25, 2012 at 04:33:13AM -0500, Jim Graham wrote: > On Wed, Jul 25, 2012 at 04:17:59AM -0500, Jim Graham wrote: > > On one list I'm on (the Chile-Heads list, fwiw), from time to time the > topic of replying to the list will come up, and the fact that most have > to do a reply-all to reply to the list, and the resulting duplicate copy > that some people get gets people irritated. I sometimes just respond > suggesting that they just configure their e-mail program to recognize > the list and to use a list-reply. Too bad their e-mail clients just > can't do that. Oh well, mine can ;-} Yeah this is a pet peeve of mine as well. I hate getting two copies of a message just because people can't figure out I read the mailing list they're responding to. At least *I* don't do thath to other people! Thanks, Mutt! -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachmentsCode Blue or Go Home!
Re: Killfiling, anyone?
* John Long [07-25-12 07:52]: > That's three votes for procmail. I guess I will have to look into it! 4 :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535@ http://linuxcounter.net
Re: OT: MTA seems to delete header lines about Content-type
On Tue, Jul 24, 2012 at 04:16:56PM +0200, Matthias Apitz wrote: > > Hello, > > I know, this a bit off-topic, but maybe someone of the mail Gurus has an > idea where to look... > > We are producing mails with UTF-8 encoded text body and a header line > telling > > Content-type text/plain; charset=UTF-8 I don't see the colon after "Content-type" but I'm assuming that's a typo. If it's not a typo, put it in :) > The mail is prepared including To/From/Subject header as a file and gets > sent with > > sendmail -t < file > > This is working fine, but there are cases where some of the involved MTA > is removing the Content-type line from the mail and of course the UTF-8 > encoded chars are looking like garbage in the MUA. > > Such a result looks like the attached header. > > Any idea why this happens or where to look for the reasons. Are you putting in a Mime-Version header field, or is that getting stripped too? (I don't see it in the example you appended) mm
Re: Killfiling, anyone?
Well, here's one vote for maildrop (from a former procmail user). They're both good. And, since I use exim, I keep telling myself that someday I'm going to try its Sieve per-user filter support. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpykwq5kWVZ1.pgp Description: PGP signature
Re: OT: MTA seems to delete header lines about Content-type
El día Wednesday, July 25, 2012 a las 09:44:47AM -0400, Mark E. Mallett escribió: > On Tue, Jul 24, 2012 at 04:16:56PM +0200, Matthias Apitz wrote: > > > > Hello, > > > > I know, this a bit off-topic, but maybe someone of the mail Gurus has an > > idea where to look... > > > > We are producing mails with UTF-8 encoded text body and a header line > > telling > > > > Content-type text/plain; charset=UTF-8 > > I don't see the colon after "Content-type" but I'm assuming that's a > typo. If it's not a typo, put it in :) yep, this was a typo; I did not have the line for cut&paste (because it gets stripped out), but I checked the original source file and it is there; > > The mail is prepared including To/From/Subject header as a file and gets > > sent with > > > > sendmail -t < file > > > > This is working fine, but there are cases where some of the involved MTA > > is removing the Content-type line from the mail and of course the UTF-8 > > encoded chars are looking like garbage in the MUA. > > > > Such a result looks like the attached header. > > > > Any idea why this happens or where to look for the reasons. > > Are you putting in a Mime-Version header field, or is that getting > stripped too? (I don't see it in the example you appended) No, should we? I inserted now in addition: MIME-Version: 1.0 In this case the mail arrives fine and the header gets re-written as: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Note: the utf-8 is now in small letters and the line splitted into two; i.e. the MTA rewrote the Content-Type header line; Does this mean that we must use in addition "MIME-Version: 1.0" header? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
Re: Killfiling, anyone?
On Jul 25, 2012 at 10:26 AM -0400, Mark H. Wood wrote: Well, here's one vote for maildrop (from a former procmail user). They're both good. And, since I use exim, I keep telling myself that someday I'm going to try its Sieve per-user filter support. I use Sieve for this kind of thing. Download my mail with getmail and send it to Dovecot's deliver sorts mail into maildirs based on the Sieve setup.
Re: OT: MTA seems to delete header lines about Content-type
On Wed, Jul 25, 2012 at 04:39:21PM +0200, Matthias Apitz wrote: > El d?a Wednesday, July 25, 2012 a las 09:44:47AM -0400, Mark E. Mallett > escribi?: > > > > Are you putting in a Mime-Version header field, or is that getting > > stripped too? (I don't see it in the example you appended) > > No, should we? Yeah, if you are using any MIME header fields you should have the MIME-Version field too (see RFC2045). > I inserted now in addition: > > MIME-Version: 1.0 > > In this case the mail arrives fine and the header gets re-written as: > > Content-Type: text/plain; > charset="utf-8" > MIME-Version: 1.0 > > Note: the utf-8 is now in small letters and the line splitted into two; > i.e. the MTA rewrote the Content-Type header line; Perhaps that means that that MTA is internalizing the header fields on input and regenerating them on output. Or maybe something else, it's hard to know. Is that the same MTA that deleted the content-type header too? > Does this mean that we must use in addition "MIME-Version: 1.0" header? I think so. Especially if that makes it work for you :) mm
Re: Killfiling, anyone?
>> That's three votes for procmail. I guess I will have to look into it! >4 :^) And me too is voting for procmail of course ☺! So it is 5.
Re: Killfiling, anyone?
Hi John!
On Mi, 25 Jul 2012, John Long wrote:
> Guys, what are you using for killfiling/mail filtering?
>
> I am using Mutt's built in POP and SMTP at this point, is there any way to
> killfile emails based on header contents? Scoring won't be enough, I want to
> delete this crap as the email is being downloaded from my mail provider.
>
> I am not looking for bayesian or other high-falutin' anti spam measures. I
> want to create my own killfile like I do with my newsreader, basically just
> creating rules that match the idiots that spam the mailing lists I'm in.
I used to have a little shell-script, that was killfiling within mutt
for me (attached). It simply generates a pattern, that can be used by
mutt to delete messages by scoring.
Additionally, I needed to set up scoring for mutt like this:
#v+
~$ cat ~/.mutt/score
##
# Scoring Definitions for Mutt/Muttng
#
# Last update: Mi 2010-02-17 22:02
#
##
set score # enable Scoring
set score_threshold_delete=0# delete messages with score 0
set score_threshold_flag=65 # auto-flag messages w/ score >= 35
set score_threshold_read=5 # mark messages w/ score <= 5 as read
# Remove all scorings
unscore *
# Default - Scoring
score '~N' +10 # new mails have a higher score than old mail
score '~A' +10 # all messages start with score 10
score '~g|~G'+2 # PGP signed / encrypted messages
score ~F +20 # flagged mails are important
score ~D =0 # this is a deleted email
score ~S =0 # superseded messages
score ~V +3 # cryptographic verified message
score '~x @256bit.org' +5# Message references one of my message
# Subject dependent scoring
score '~s [Vv][Ii][Mm]' +10 # vim
score '~s [Mm][Uu][Tt][Tt]' +10 # mutt
score '~s [Ss][Hh][Ee][Ll][Ll]' +10 # shell
score '~s [Bb][Aa][Ss][Hh]' +10 # bash
score '~s [Zz][Ss][Hh]' +10 # zsh
# The good one ;)
score '~P' =20 # Message is from me
# SPAM
score '~f @aol.com' -2 # AOL is usually less important
score '~f webmaster@*'-2 # Webmasters kidnapped by evil cult :>
score '~s ^test$' -2 # all messages w/ subject "test" are killed
score '~s sex | ~s adult' -10 # STFU
score '~f anonymous' -10 # Yeah. Sure. Evil hackers from Serbia.
score '~=' - # all duplicates are killed
score '~s ^unsubscribe$ !(~p|~P|~Q|~F)' - # all msgs w/ subject
"unsubscribe" not by myself are killed
#score '!~f@' -10 # no mail address present?
score "~f '^([^ <>@]+ ){5,}'" -2 # a realname consisting of >=5 portions is
invalid, too
score "!~s .*"-2 # no Subject line
source ~/.mutt/score_gen
$~
#v-
That was basically it. It still works, although I don't use it anymore.
PS: No, procmail was no option, since I used sieve scripts to deliver my
mails.
regards,
Christian
mutt_score.sh
Description: Bourne shell script
Re: OT: MTA seems to delete header lines about Content-type
El día Wednesday, July 25, 2012 a las 12:49:31PM -0400, Mark E. Mallett escribió: > On Wed, Jul 25, 2012 at 04:39:21PM +0200, Matthias Apitz wrote: > > El d�a Wednesday, July 25, 2012 a las 09:44:47AM -0400, Mark E. Mallett > > escribi�: > > > > > > Are you putting in a Mime-Version header field, or is that getting > > > stripped too? (I don't see it in the example you appended) > > > > No, should we? > > Yeah, if you are using any MIME header fields you should have the > MIME-Version field too (see RFC2045). We have not set any MIME header fields, only Content-type; I checked the source of the resulting mail and se now that UTF-8 coded chars are represented like this, an "�" is arriving as "=C3=BC"; this is not what we wanted, even if the MUA can show them fine; but what about other software reading such mails? I'd prefer plain UTF-8 body. matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
Re: OT: MTA seems to delete header lines about Content-type
On Wed, Jul 25, 2012 at 08:58:32PM +0200, Matthias Apitz wrote: > El d??a Wednesday, July 25, 2012 a las 12:49:31PM -0400, Mark E. Mallett > escribi??: > > > On Wed, Jul 25, 2012 at 04:39:21PM +0200, Matthias Apitz wrote: > > > El d?a Wednesday, July 25, 2012 a las 09:44:47AM -0400, Mark E. Mallett > > > escribi?: > > > > > > > > Are you putting in a Mime-Version header field, or is that getting > > > > stripped too? (I don't see it in the example you appended) > > > > > > No, should we? > > > > Yeah, if you are using any MIME header fields you should have the > > MIME-Version field too (see RFC2045). > > We have not set any MIME header fields, only Content-type; Content-Type is a MIME header field, per the RFC I mentioned. Also, go here: http://www.iana.org/assignments/message-headers/perm-headers.html find Content-Type, which refers you to RFC 4021; go there, find Content-Type, which refers you to RFC 2045; which tells you that you need a Mime-Version header field :) > I checked the source of the resulting mail and se now that UTF-8 coded > chars are represented like this, an "?" is arriving as "=C3=BC"; this is > not what we wanted, even if the MUA can show them fine; but what about other > software reading such mails? I'd prefer plain UTF-8 body. Well, as a gross generalization: it looks like it's doing a quoted-printable content-transfer-encoding, which it's allowed to do in order to convert 8-bit data (or any bytes, really) to something more palatable to its context or configuration. An MTA shouldn't be accepting raw 8-bit without negotation, though some do, and it's free to change the encoding when it e.g. talks to another MTA or to a delivery agent. In other words, you as a sender may not get to have a say as to how the receiver or any intermediate MTA encodes it. All rather far afield from mutt, though. mm
Re: OT: MTA seems to delete header lines about Content-type
El día Wednesday, July 25, 2012 a las 03:28:11PM -0400, Mark E. Mallett escribió: > All rather far afield from mutt, though. > > mm Fully agreed. Thanks for pointing me into the right direction. matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
