Re: Something doofuzzled in a * ^To: line.
Duane Hill a écrit : On Mon, 23 Feb 2009, Gene Heskett wrote: I've seen both. but I didn't see a Bcc: line at all. There is no Bcc: line (email header). Therefore, a Bcc: is supplied as a RCPT TO during SMTP time and that is it. In theory, there is a Bcc: header. But since you don't want non Bcc-ed recipients to know that there was a Bcc, such a header shouldn't be added, except if different copies are sent (in a way to guarantee that a non Bcc-ed recipient shouldn't know there was a Bcc at all, and a Bcc-ed recipient shouldn't know there were other Bcc-ed addresses). This should all be done in the MUA. An MSA could alter submitted messages, but the MUA is the user interface, so that's the right place to handle this stuff. (a (very) long time ago, I've found a bug in Eudora: if you send a message with a Bcc, then you chose to forward the sent message, then the Bcc: header will be disclosed in the forwarded copie!).
Re: Something doofuzzled in a * ^To: line.
On Tue, February 24, 2009 04:03, Duane Hill wrote: On Mon, 23 Feb 2009, Gene Heskett wrote: I've seen both. but I didn't see a Bcc: line at all. There is no Bcc: line (email header). Therefore, a Bcc: is supplied as a RCPT TO during SMTP time and that is it. no ! mua add BCC: recipients mta remove BCC: before sending indiviual msgs to recipients recipiens newer se the mua BCC header -- http://localhost/ 100% uptime and 100% mirrored :)
Re: Something doofuzzled in a * ^To: line.
On Tue, 2009-02-24 at 01:08 -0500, Gene Heskett wrote:
On Tuesday 24 February 2009, SM wrote:
You could add a rule to catch the no To-header comment.
Humm, if it can't find the unlisted stuff in the same line...
There is no line break. Just as I suspected yesterday, I still suspect
your copy-n-paste method to have inserted the newline. Procmail works
with the raw message and doesn't look at the rendered KMail display.
Btw, procmail concatenates multi-line headers and handles it
transparently for you anyway.
Would this work?
:0:
*^*no To-header on input*
/dev/null
Nope, it wouldn't. Procmail uses REs, not shell-style globbing.
If you don't want to anchor your condition REs at the beginning of the
line, don't. IMHO you'd better do though, for multiple reasons -- speed,
and not to match any arbitrary header but the To header only.
That said, I do agree with Martin and John. The absence of a real
recipient in the To header is NOT sufficient to silently discard mail.
Even more so, since the POP3 server appears to have rewritten that
stuff.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Something doofuzzled in a * ^To: line.
On Tuesday 24 February 2009, Karsten Bräckelmann wrote: On Tue, 2009-02-24 at 01:08 -0500, Gene Heskett wrote: On Tuesday 24 February 2009, SM wrote: You could add a rule to catch the no To-header comment. Humm, if it can't find the unlisted stuff in the same line... There is no line break. Just as I suspected yesterday, I still suspect your copy-n-paste method to have inserted the newline. Procmail works with the raw message and doesn't look at the rendered KMail display. Btw, procmail concatenates multi-line headers and handles it transparently for you anyway. Would this work? :0: *^*no To-header on input* /dev/null Nope, it wouldn't. Procmail uses REs, not shell-style globbing. I never claimed to understand regex's. I know the ^ anchors the start of the search to the start of the line, and that the first * is needed to into a recipe, but how does one go about allowing it to search the whole line for the given character sequence, triggering on finding it at some arbitrary location in that line? If grep can do it, why can't procmail? IMO the Docs suck a deep space quality vacuum in re these details. If there exists a decent tut on this subject, please point me at it. If you don't want to anchor your condition REs at the beginning of the line, don't. IMHO you'd better do though, for multiple reasons -- speed, and not to match any arbitrary header but the To header only. Are you saying that if I remove the ^ and second *, then it will search the whole header? Testing that now... That said, I do agree with Martin and John. The absence of a real recipient in the To header is NOT sufficient to silently discard mail. Even more so, since the POP3 server appears to have rewritten that stuff. If I was an ISP, maybe. But I'm just sick of junk mail if I miss a free offer for 20 boxes of viagra, well... :) Thanks. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) You will be a winner today. Pick a fight with a four-year-old.
Re: Something doofuzzled in a * ^To: line.
On Tue, 2009-02-24 at 12:47 -0500, Gene Heskett wrote:
On Tuesday 24 February 2009, Karsten Bräckelmann wrote:
Would this work?
:0:
*^*no To-header on input*
/dev/null
Nope, it wouldn't. Procmail uses REs, not shell-style globbing.
I never claimed to understand regex's. I know the ^ anchors the start of the
search to the start of the line, and that the first * is needed to into a
recipe, but how does one go about allowing it to search the whole line for
the given character sequence, triggering on finding it at some arbitrary
location in that line? If grep can do it, why can't procmail?
*sigh* OK, slow down a bit. You're mixing procmail and REs here.
Yes, the very first * denotes a condition in the procmail recipe. Also
yes, ^ anchors your RE at the beginning of the string. Procmail is no
different than grep in this regard.
grep undisclosed raw-message-headers-only.file
Limiting to the headers only, which is the procmail default. Just to
prevent grep matches in the body. Now that trivial grep will check ALL
headers -- for example, including the Subject. If you want to limit your
grep to a specific header, you need to anchor your RE. Exactly the same
with procmail. (With the notable exception of procmail properly treating
multi-line headers, which grep of course doesn't. Add formail to the mix
for that. ;)
So you want to match a specific header (read: the beginning of a given
line), and match a string that might appear anywhere in that header.
That's basically whatever there is between the two. In RE, that's any
char, any number of times. The good old /.*/, and the RE becomes:
^Header: .*Catch Phrase
Procmail, just like grep, is line oriented -- whereas SA rules make the
syntax for dealing with that easier. For reference, and in a vain
attempt to get back on-topic:
header MY_CATCH_PHRASE Header =~ /Catch Phrase/
The rule is limited to header Header, but the RE itself is not anchored
to the beginning, thus we don't need to care about stuff between them.
Sorry, Gene -- this is most *basic* stuff.
IMO the Docs suck a deep space quality vacuum in re these details. If there
exists a decent tut on this subject, please point me at it.
man procmailex
For RE docs, see http://perldoc.perl.org/perlre.html in particular the
Quick-Start and Tutorial introduction mentioned early. Note though, that
procmail REs are quite different from that in anything even mildly
advanced.
If you don't want to anchor your condition REs at the beginning of the
line, don't. IMHO you'd better do though, for multiple reasons -- speed,
and not to match any arbitrary header but the To header only.
Are you saying that if I remove the ^ and second *, then it will search the
whole header? Testing that now...
Yes. ALL headers, since you didn't specify a header. Can appear anywhere
in the line. See above for properly limiting to a specific header.
FWIW, the second * (actually the first one in your RE) is just bad.
I'd expect procmail to complain about that.
That said, I do agree with Martin and John. The absence of a real
recipient in the To header is NOT sufficient to silently discard mail.
Even more so, since the POP3 server appears to have rewritten that
stuff.
If I was an ISP, maybe. But I'm just sick of junk mail if I miss a free
offer for 20 boxes of viagra, well... :)
Or the wedding of a friend. [1] Coincidentally, I sent some mail to Bcc
only recipients the other day. You would discard it. Good one...
Again, I *strongly* suggest to score it a point or two in SA, if you are
so inclined. Leaving at least a chance for legitimate mail to survive
it.
guenther
[1] No, not me. :)
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Something doofuzzled in a * ^To: line.
On Tue, 2009-02-24 at 12:47 -0500, Gene Heskett wrote: I never claimed to understand regex's. I know the ^ anchors the start of the search to the start of the line, and that the first * is needed to into a recipe, but how does one go about allowing it to search the whole line for the given character sequence, triggering on finding it at some arbitrary location in that line? If grep can do it, why can't procmail? Gene, this page has helped me a lot when I was first setting up procmail. http://lipas.uwasa.fi/~ts/info/proctips.html HTH Chris -- KeyID 0xE372A7DA98E6705C Live - Alice Cooper - Elected (Absolute Classic Rock, live from London, UK Hi BR MP3) signature.asc Description: This is a digitally signed message part
Re: Something doofuzzled in a * ^To: line.
On Tuesday 24 February 2009, Chris wrote: On Tue, 2009-02-24 at 12:47 -0500, Gene Heskett wrote: I never claimed to understand regex's. I know the ^ anchors the start of the search to the start of the line, and that the first * is needed to into a recipe, but how does one go about allowing it to search the whole line for the given character sequence, triggering on finding it at some arbitrary location in that line? If grep can do it, why can't procmail? Gene, this page has helped me a lot when I was first setting up procmail. http://lipas.uwasa.fi/~ts/info/proctips.html HTH Chris Thanks Chris, bookmarked for when I have at least one eye open. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Your goose is cooked. (Your current chick is burned up too!)
Something doofuzzled in a * ^To: line.
Greetings; Using fetchmail-procmail | spamc |procmail - user mailbox or /dev/null. I've had zip luck getting a trigger line based on Undisclosed Recipients:, or Unlisted Recipients: here, so I called up my .procmailrc and tried to enter the check phrase by doing a copy/paste from the kmail displayed line when in show all headers mode. But, when pasting that into vim, there is an invisible linefeed occupying the underscores place in the header line, and it doesn't show up in the show all headers display. The input line looks like this: To: unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com But copy/pastes as: To: _ unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com Where the underscore is the hidden line feed. I save the message, and inspected it with khexedit, but the saved version does not have an 0x0a there. Anybody got an idea how the spammers have managed that? And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header. Thank you for any insight offered. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) xtifr Athena Desktop Environment! In your hearts, you *know* it's the right choice! :) * Knghtbrd THWAPS xtifr
Re: Something doofuzzled in a * ^To: line.
It sounds like an issue w/ kmail/vim and not so much a nefarious spammer ability. And I'm not sure what you mean by unlisted header. If you mean: [other headers] To: unlisted header Then the answer is unlisted header is actually the first line of the body. On Mon, Feb 23, 2009 at 5:55 PM, Gene Heskett gene.hesk...@verizon.net wrote: I've had zip luck getting a trigger line based on Undisclosed Recipients:, or Unlisted Recipients: here, so I called up my .procmailrc and tried to enter the check phrase by doing a copy/paste from the kmail displayed line when in show all headers mode. But, when pasting that into vim, there is an invisible linefeed occupying the underscores place in the header line, and it doesn't show up in the show all headers display. The input line looks like this: To: unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com But copy/pastes as: To: _ unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com Where the underscore is the hidden line feed. I save the message, and inspected it with khexedit, but the saved version does not have an 0x0a there. Anybody got an idea how the spammers have managed that? And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header.
Re: Something doofuzzled in a * ^To: line.
Oh, and having a sample mail via pastebin/etc would be handy if you want more commentary about the mail. :) On Mon, Feb 23, 2009 at 6:52 PM, Theo Van Dinter felic...@apache.org wrote: It sounds like an issue w/ kmail/vim and not so much a nefarious spammer ability. And I'm not sure what you mean by unlisted header. If you mean: [other headers] To: unlisted header Then the answer is unlisted header is actually the first line of the body. On Mon, Feb 23, 2009 at 5:55 PM, Gene Heskett gene.hesk...@verizon.net wrote: I've had zip luck getting a trigger line based on Undisclosed Recipients:, or Unlisted Recipients: here, so I called up my .procmailrc and tried to enter the check phrase by doing a copy/paste from the kmail displayed line when in show all headers mode. But, when pasting that into vim, there is an invisible linefeed occupying the underscores place in the header line, and it doesn't show up in the show all headers display. The input line looks like this: To: unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com But copy/pastes as: To: _ unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com Where the underscore is the hidden line feed. I save the message, and inspected it with khexedit, but the saved version does not have an 0x0a there. Anybody got an idea how the spammers have managed that? And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header.
Re: Something doofuzzled in a * ^To: line.
On Mon, 2009-02-23 at 17:55 -0500, Gene Heskett wrote: Anybody got an idea how the spammers have managed that? Sorry, I can't help with the invisible stuff, but I do know a little about the other part of your question: And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header. 'Undisclosed recipients:' and its variants: These are created by a lot of current MUAs and some MTAs (Microsoft Exchange V6.5 amongst others). I've usually seen this in mass mailings to members of organisations that use blind copy addressing to hide members' addresses from other recipients. It often appears as the only address term for a Bcc: header. The string Undisclosed recipients: is actually a legal group address name. It would appear that some MTAs deal with Bcc group addresses by generating a mail message for each address in the group with the group address name left in the To:, CC: or BCC: header and the actual address put in the envelope header. As just two or three spelling variants exist, I'd also speculate that some MTAs treat this group address name as 'special', i.e. it, rather than a control flag, determines whether blind copies are sent. Some of these MTAs are fed from MUAs or bulk mailers that accept ';' as a list separator in place of the more usual comma: this causes some parsers some grief which result in them including the semicolon as part of the address rather than stripping it off. In the last year I haven't seen any mail with Unlisted recipients, just variations on Undisclosed recipients. I have seen some occurrences in spam but by far the majority has been in messages sent to members of reasonably large (150+) groups that I belong to. IMO the appearance of Undisclosed recipients: in a list of addresses should not be taken as an indication of spam, but as always ymmv. The following Java snippet seems to reliably catch all variations on the theme: String temp = address.replaceAll([\\.\\-:;], ); temp = temp.trim(); temp = temp.toLowerCase(); boolean undisclosed = (temp.compareTo(undisclosed recipients) == 0); In other words, within the address string: a) replace each occurrence of '.' (full stop), '-' (hyphen), ':' (colon) and ';' (semicolon) with a single space b) remove all leading and trailing spaces c) convert the string to lower case d) set 'undisclosed' TRUE if the resulting string is undisclosed recipients Thank you for any insight offered. HTH Martin
Re: Something doofuzzled in a * ^To: line.
On Tue, 24 Feb 2009, Martin Gregorie wrote: On Mon, 2009-02-23 at 17:55 -0500, Gene Heskett wrote: And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header. Bad idea to poison-pill that. IMO the appearance of Undisclosed recipients: in a list of addresses should not be taken as an indication of spam, but as always ymmv. Agreed. For example, if I send an email to several of my correspondents but I don't want them to know who else I've sent the message to (because I respect their privacy), I'll only use BCC:. This results in an empty TO:, which will likely get populated with some variant of undisclosed recipients. The message is legitimate, classifying it as spam for undisclosed recipient would be a FP. Now if a particular variant of that text didn't FP much, you'd be justified in giving it a point. Anybody with big corpa want to investigate this? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- It is criminal to teach a man not to defend himself when he is the constant victim of brutal attacks. -- Malcolm X (1964) --- 34 days since Obama's inauguration and still no unicorn!
Re: Something doofuzzled in a * ^To: line.
Martin Gregorie mar...@gregorie.org wrote: The string Undisclosed recipients: is actually a legal group address name. No, it is not. It needs to be closed with ';' to be legal. This... To: Undisclosed recipients:; ... conforms to standard, with or without spaces around the ':' and ';' characters. That's a now-rare variant of an address spec which could possibly be like this... To: List: us...@example.com, us...@example.com; ... where 'List' is the name of the list, and then a list of any number of comma-separated addresses follows, and then ';' ends the list. The undisclosed recipients:; notation, the only case commonly seen, is just a list with no addresses in it. Also somewhat common is... To: Members of the List Blablabla:; ... as written by Listserv. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology
Re: Something doofuzzled in a * ^To: line.
On Mon, Feb 23, 2009 at 5:55 PM, Gene Heskett wrote:
[...] by doing a copy/paste from the kmail displayed line when in
show all headers mode.
On Mon, 2009-02-23 at 18:52 -0500, Theo Van Dinter wrote:
Oh, and having a sample mail via pastebin/etc would be handy if you
want more commentary about the mail. :)
And please make sure to paste the RAW message.
Don't use KMail myself, but this definitely sounds like a copy/paste
issue. That mysterious show all headers mode, does it by any chance
use HTML or whatever else to somewhat *format* the mail and header
display you copied from?
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Something doofuzzled in a * ^To: line.
On Mon, 2009-02-23 at 20:00 -0500, Joseph Brennan wrote: Martin Gregorie mar...@gregorie.org wrote: The string Undisclosed recipients: is actually a legal group address name. No, it is not. It needs to be closed with ';' to be legal. This... To: Undisclosed recipients:; ... conforms to standard, with or without spaces around the ':' and ';' characters. That's a now-rare variant of an address spec which could possibly be like this... To: List: us...@example.com, us...@example.com; Noted: thanks for the correction. I hadn't noticed that, only that some MTAs, notably Outlook, accepts and sends out semicolons as separators in a manually entered list of recipients. This causes JavaMail to declare the header to be illegal unless you turn off strict parsing, which is the default. Martin
Re: Something doofuzzled in a * ^To: line.
On Monday 23 February 2009, Theo Van Dinter wrote: Oh, and having a sample mail via pastebin/etc would be handy if you want more commentary about the mail. :) http://pastebin.ca/1345467 Thanks. The question is how to craft a procmail rule that will trigger on the 'unlisted' bit. On Mon, Feb 23, 2009 at 5:55 PM, Gene Heskett gene.hesk...@verizon.net wrote: I've had zip luck getting a trigger line based on Undisclosed Recipients:, or Unlisted Recipients: here, so I called up my .procmailrc and tried to enter the check phrase by doing a copy/paste from the kmail displayed line when in show all headers mode. But, when pasting that into vim, there is an invisible linefeed occupying the underscores place in the header line, and it doesn't show up in the show all headers display. The input line looks like this: To: unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com But copy/pastes as: To: _ unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com Where the underscore is the hidden line feed. I save the message, and inspected it with khexedit, but the saved version does not have an 0x0a there. Anybody got an idea how the spammers have managed that? And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Q: What do you call the money you pay to the government when you ride into the country on the back of an elephant? A: A howdah duty.
Re: Something doofuzzled in a * ^To: line.
On Monday 23 February 2009, Martin Gregorie wrote: On Mon, 2009-02-23 at 17:55 -0500, Gene Heskett wrote: Anybody got an idea how the spammers have managed that? Sorry, I can't help with the invisible stuff, but I do know a little about the other part of your question: And better yet, how to defend against it as I'd like to /dev/null any message with an unlisted header. 'Undisclosed recipients:' and its variants: These are created by a lot of current MUAs and some MTAs (Microsoft Exchange V6.5 amongst others). I've usually seen this in mass mailings to members of organisations that use blind copy addressing to hide members' addresses from other recipients. It often appears as the only address term for a Bcc: header. The string Undisclosed recipients: is actually a legal group address name. It would appear that some MTAs deal with Bcc group addresses by generating a mail message for each address in the group with the group address name left in the To:, CC: or BCC: header and the actual address put in the envelope header. As just two or three spelling variants exist, I'd also speculate that some MTAs treat this group address name as 'special', i.e. it, rather than a control flag, determines whether blind copies are sent. Some of these MTAs are fed from MUAs or bulk mailers that accept ';' as a list separator in place of the more usual comma: this causes some parsers some grief which result in them including the semicolon as part of the address rather than stripping it off. In the last year I haven't seen any mail with Unlisted recipients, just variations on Undisclosed recipients. I've seen both. but I didn't see a Bcc: line at all. I have seen some occurrences in spam but by far the majority has been in messages sent to members of reasonably large (150+) groups that I belong to. IMO the appearance of Undisclosed recipients: in a list of addresses should not be taken as an indication of spam, but as always ymmv. The following Java snippet seems to reliably catch all variations on the theme: String temp = address.replaceAll([\\.\\-:;], ); temp = temp.trim(); temp = temp.toLowerCase(); boolean undisclosed = (temp.compareTo(undisclosed recipients) == 0); In other words, within the address string: a) replace each occurrence of '.' (full stop), '-' (hyphen), ':' (colon) and ';' (semicolon) with a single space b) remove all leading and trailing spaces c) convert the string to lower case d) set 'undisclosed' TRUE if the resulting string is undisclosed recipients Sounds neat, but I know squat about java, sorry. Thanks. Thank you for any insight offered. HTH Martin -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Q: What do you call the money you pay to the government when you ride into the country on the back of an elephant? A: A howdah duty.
Re: Something doofuzzled in a * ^To: line.
On Monday 23 February 2009, Karsten Bräckelmann wrote: On Mon, Feb 23, 2009 at 5:55 PM, Gene Heskett wrote: [...] by doing a copy/paste from the kmail displayed line when in show all headers mode. On Mon, 2009-02-23 at 18:52 -0500, Theo Van Dinter wrote: Oh, and having a sample mail via pastebin/etc would be handy if you want more commentary about the mail. :) And please make sure to paste the RAW message. Don't use KMail myself, but this definitely sounds like a copy/paste issue. That mysterious show all headers mode, does it by any chance use HTML or whatever else to somewhat *format* the mail and header display you copied from? AFAIK, its raw, at http://pastebin.ca/1345467 -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) If God had wanted us to be concerned for the plight of the toads, he would have made them cute and furry. -- Dave Barry
Re: Something doofuzzled in a * ^To: line.
On Mon, 23 Feb 2009, Gene Heskett wrote: I've seen both. but I didn't see a Bcc: line at all. There is no Bcc: line (email header). Therefore, a Bcc: is supplied as a RCPT TO during SMTP time and that is it.
Re: Something doofuzzled in a * ^To: line.
On Mon, 2009-02-23 at 21:41 -0500, Gene Heskett wrote: On Monday 23 February 2009, Martin Gregorie wrote: In the last year I haven't seen any mail with Unlisted recipients, just variations on Undisclosed recipients. I've seen both. but I didn't see a Bcc: line at all. You wouldn't, the BCC stuff only exists at the SMTP level. That said, I have seen _blank_ BCC: headers. A blank BCC: header might be a useful spam indicator. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Phobias should not be the basis for laws. --- 34 days since Obama's inauguration and still no unicorn!
Re: Something doofuzzled in a * ^To: line.
On Mon, 2009-02-23 at 21:41 -0500, Gene Heskett wrote:
Sounds neat, but I know squat about java, sorry.
OK, I think something like this should match:
header UNDISC_RECIP To ~= /un(disclos|list)ed( |-)recipient[:;]{1,2}/i
Disclaimer: this has not been tested or compiled
As I said before, I don't think Undisclosed-recipients:; should be used
to score spam.
However, Unlisted-recipients:; may be a spam candidate. Its either
extremely rare, in my mail stream anyway, or I'm not seeing it because
other attributes are causing messages containing it to be treated as
spam: I whitelist anybody I've written to and discard any incoming
that's still labelled as spam.
Martin
Re: Something doofuzzled in a * ^To: line.
At 18:38 23-02-2009, Gene Heskett wrote: The input line looks like this: To: unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com Is your MTA or POP3 client adding the @gmail-pop.l.google.com at the end of that line? You could add a rule to catch the no To-header comment. Regards, -sm
Re: Something doofuzzled in a * ^To: line.
On Tuesday 24 February 2009, SM wrote: At 18:38 23-02-2009, Gene Heskett wrote: The input line looks like this: To: unlisted-recipients:; (no To-header on input)@gmail-pop.l.google.com Is your MTA or POP3 client adding the @gmail-pop.l.google.com at the end of that line? Not that I know of. Fetchmail occasionally squawks about a race in the PEEK_MSG function, maybe a couple times a day. ~/.procmailrc has no such edit line in it. Obviously it did come in through my gmail account. You could add a rule to catch the no To-header comment. Humm, if it can't find the unlisted stuff in the same line... Would this work? :0: *^*no To-header on input* /dev/null In for testing. :-) Thanks. Regards, -sm -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I'm totally DESPONDENT over the LIBYAN situation and the price of CHICKEN ...
Re: Something doofuzzled in a * ^To: line.
At 22:08 23-02-2009, Gene Heskett wrote: Not that I know of. Fetchmail occasionally squawks about a race in the PEEK_MSG function, maybe a couple times a day. ~/.procmailrc has no such edit line in it. Obviously it did come in through my gmail account. The MSG_PEEK is used on sockets and that's where the race condition occurs. Humm, if it can't find the unlisted stuff in the same line... Your software may have added a line wrap. :0: *^*no To-header on input* /dev/null I haven't tested that recipe. It should work. You can enable the Procmail log file for debugging. Regards, -sm
