Re: OBSCURED_EMAIL ?
Daryl C. W. O'Shea wrote: > Yeah, I could. I'd rather just point you at the text you quoted above > (^ really is substituted for @) or the email Theo sent earlier > suggesting the same thing. Combine that with rot13, or any other > rotNN you prefer. Last comment from my side - what I'm having a bit of an issue with is this seemingly arbitrary substitution of '^' for '@', and that the rule that is desribed as "Message seems to contain rot13ed address" expects this, but couldn't actually catch anything that _was_ rot13'ed. The only other rotNN I know of is rot47, and that doesn't turn an '@' into a '^' either. > Yes, in your particular case it wasn't your email addressed obscured, > it was a hit on a binary part. Very true - for me, the focus has already shifted to the issue of embedded uuencoded files, which I think is more critical. > Sometimes rules hit things they're not intended to, or things they are > intended to hit but in ham. That's why SA is a score based system. > If you find that this particular rule is causing you problems perhaps > you may want to consider assigning it a zero score. Certainly. I was merely trying to bring it others' attention that this rule in my opinion has a much too high default score, and it does more bad than good. /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Per Jessen wrote: Daryl C. W. O'Shea wrote: Per Jessen wrote: To me it's a pretty much moot point - OBSCURED_EMAIL with its 1.6points is of little use. I would certainly suggest reducing the default score to a lot less. (are there really other single substitution methods in common use that translate '@' to '^' ?) Yeah -- that would be the reason why there's a rule to look for such a thing. We don't just make rules up for the hell of it. Can you list any of these methods? We know it's not rot13. Yeah, I could. I'd rather just point you at the text you quoted above (^ really is substituted for @) or the email Theo sent earlier suggesting the same thing. Combine that with rot13, or any other rotNN you prefer. Yes, in your particular case it wasn't your email addressed obscured, it was a hit on a binary part. Since we know that the hit wasn't on an encoded form of your email address there's little point in this debate -- there's no substitution method that is going to make your address magically appear. Sometimes rules hit things they're not intended to, or things they are intended to hit but in ham. That's why SA is a score based system. If you find that this particular rule is causing you problems perhaps you may want to consider assigning it a zero score. Daryl
Re: OBSCURED_EMAIL ?
Daryl C. W. O'Shea wrote: > Per Jessen wrote: > >> To me it's a pretty much moot point - OBSCURED_EMAIL with its >> 1.6points >> is of little use. I would certainly suggest reducing the default >> score to a lot less. (are there really other single substitution >> methods in common use that translate '@' to '^' ?) > > Yeah -- that would be the reason why there's a rule to look for such a > thing. We don't just make rules up for the hell of it. Can you list any of these methods? We know it's not rot13. /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Per Jessen wrote: To me it's a pretty much moot point - OBSCURED_EMAIL with its 1.6points is of little use. I would certainly suggest reducing the default score to a lot less. (are there really other single substitution methods in common use that translate '@' to '^' ?) Yeah -- that would be the reason why there's a rule to look for such a thing. We don't just make rules up for the hell of it. Daryl
Re: OBSCURED_EMAIL ?
From: "Kelson" <[EMAIL PROTECTED]>
Per Jessen wrote:
Theo Van Dinter wrote:
On Thu, May 31, 2007 at 09:46:56AM +0200, Per Jessen wrote:
I've been looking at what a rot13'ed email-address looks like, and it
doesn't come close to matching the pattern above.
rot13 is a common/well-defined version of a single substitution
cipher. This rule tries to match those, not the rot13 a-m <-> n-z
mapping specifically.
Then why is the pattern very specific wrt '^' and '(' ?
Because it's very common (or at least was at one time) for spammers to
rot13 the target addresses and then do those specific substitutions.
Or base64 or other "obvious" but not rot13 encodings are often used.
{^_^}
Re: OBSCURED_EMAIL ?
--=_20070103150623_67248 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Server .138 The email attached has been identified by one of our team as legitimate but unfortunately was incorrectly tagged as SPAM. The email address has been whitelisted to ensure this will not happen again and we are currently looking into the reasons why this happened. No mail has been lost as the quarantined mail folder is continuously checked by members of Team Genesis, but please accept our apologies for any inconvenience caused. Your SPAM scanning system; Ullyses is continually being upgraded and refined so we anticipate a steadily decreasing number of incidents like this as the system learns your personal profile. If you feel that you are receiving an inappropriate amount of SPAM then can we ask you to contact us either by email to: [EMAIL PROTECTED] or call your Genesis representative who will be happy to assist. Please do not respond to this email address as it is automatically generated but submit any queries to: [EMAIL PROTECTED] Thank you and take care Mark --=_20070103150623_67248 Content-Type: message/rfc822; name="originalmessage.msg" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="originalmessage.msg" Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by genesismaildefence.com with SMTP; 31 May 2007 14:30:22 +0100 Received: (qmail 68317 invoked by uid 500); 31 May 2007 13:03:24 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk list-help: <mailto:[EMAIL PROTECTED]> list-unsubscribe: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:users@spamassassin.apache.org> List-Id: Delivered-To: mailing list users@spamassassin.apache.org Received: (qmail 68308 invoked by uid 99); 31 May 2007 13:03:24 - Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 May 2007 06:03:24 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [217.8.220.67] (HELO mail.local.net) (217.8.220.67) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 May 2007 06:03:19 -0700 Received: from [192.168.2.113] (io.local.net [192.168.2.113]) by mail.local.net (Postfix) with ESMTP id 409C0D4251 for ; Thu, 31 May 2007 15:02:59 +0200 (CEST) Message-ID: <[EMAIL PROTECTED]> Date: Thu, 31 May 2007 15:02:58 +0200 From: Per Jessen <[EMAIL PROTECTED]> User-Agent: Thunderbird 1.5.0.8 (X11/20060911) MIME-Version: 1.0 To: users@spamassassin.apache.org Subject: Re: OBSCURED_EMAIL ? References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Matthias Haegele wrote: >> Yep, that should work - I'll have to obscure the attachments too though: >> >> http://jessen.ch/files/problem-with-missing-content-type2 > > > scnr: > War ja klar dass sowas (Müll) nur nur aus irgendeiner Besprechung kommen > kann ;-). Matthias, FYI, I can't reply to you directly - your mail-server is rejecting all emails from "computer.org". (due to rfc-ignorant). /Per Jessen, Zürich *** Qmail-Scanner Quarantine Envelope Details Begin *** X-Antivirus-GenesisGroup-Mail-From: "[EMAIL PROTECTED]" via dp-5019 X-Antivirus-GenesisGroup-Rcpt-To: "[EMAIL PROTECTED]" X-Antivirus-GenesisGroup: 1.25st ( problem Found. Processed in 78.603463 secs) process 4596 Quarantine-Description: SPAM exceeds "quarantine" threshold - hits=3.5/3.2 SA_REPORT hits = 3.5/3.2 -0.0 SPF_PASS SPF: sender matches SPF record 0.0 BOTNET_SOHORelay might be a SOHO mail server [botnet_soho,ip=140.211.11.2,maildomain=spamassassin.apache.org] 1.0 namecheck_bad BODY: Invalid username for sender 0.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.] 1.4 GENESIS_USERCHECK HEADER: 1.0 GENESIS_REMOTESMTP BODY: 25/TCP not listening on remote host 0.1 AWLAWL: From: address is in the auto white-list *** Qmail-Scanner Envelope Details End *** --=_20070103150623_67248--
Re: OBSCURED_EMAIL ?
Theo Van Dinter wrote: > On Thu, May 31, 2007 at 07:15:02PM +0200, Per Jessen wrote: >> Anyway, maybe it makes sense to some to look for incorrectly rot13'd >> email-addresses, but why not catch the correctly rot13'd also? > > Is anyone just using rot13 for address identification? > And if so, are there enough people doing it to make the rule > worthwhile? And if so, is there a computationally easy way to > distinguish "[EMAIL PROTECTED]" from "[EMAIL PROTECTED]" ? They > both look like valid email addresses from a simple RE standpoint. > > The only way I can think of is to insert the known valid TLDs into the > RE, which becomes painful. Also, some TLDs (country codes) rot13 > translate into other valid TLDs: it/vg, at/ng, se/fr, etc. > > In the end, I would guess it doesn't happen enough to make it > worthwhile to look for, whereas the other single substitution methods > were being used a lot at one point. To me it's a pretty much moot point - OBSCURED_EMAIL with its 1.6points is of little use. I would certainly suggest reducing the default score to a lot less. (are there really other single substitution methods in common use that translate '@' to '^' ?) /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Per Jessen wrote:
Theo Van Dinter wrote:
On Thu, May 31, 2007 at 09:46:56AM +0200, Per Jessen wrote:
I've been looking at what a rot13'ed email-address looks like, and it
doesn't come close to matching the pattern above.
rot13 is a common/well-defined version of a single substitution
cipher. This rule tries to match those, not the rot13 a-m <-> n-z
mapping specifically.
Then why is the pattern very specific wrt '^' and '(' ?
Because it's very common (or at least was at one time) for spammers to
rot13 the target addresses and then do those specific substitutions.
--
Kelson Vibber
SpeedGate Communications
Re: OBSCURED_EMAIL ?
On Thu, May 31, 2007 at 07:15:02PM +0200, Per Jessen wrote: > Anyway, maybe it makes sense to some to look for incorrectly rot13'd > email-addresses, but why not catch the correctly rot13'd also? Is anyone just using rot13 for address identification? And if so, are there enough people doing it to make the rule worthwhile? And if so, is there a computationally easy way to distinguish "[EMAIL PROTECTED]" from "[EMAIL PROTECTED]" ? They both look like valid email addresses from a simple RE standpoint. The only way I can think of is to insert the known valid TLDs into the RE, which becomes painful. Also, some TLDs (country codes) rot13 translate into other valid TLDs: it/vg, at/ng, se/fr, etc. In the end, I would guess it doesn't happen enough to make it worthwhile to look for, whereas the other single substitution methods were being used a lot at one point. -- Randomly Selected Tagline: "I just love getting wild puzzled stares when I mention that I'm using a computer that isn't physically in front of me..." - Michelle Vadeboncoeur pgphO4pr0plOy.pgp Description: PGP signature
Re: OBSCURED_EMAIL ?
Theo Van Dinter wrote: >> Not really. A rot13 of an email-address should not substitute '@' >> and '.'. > > Again, don't think of rot13 specifically. Single substition cipher. Possibly, but in that case the rule doesn't even remotely work according to its description. It will never match a correct rot13 substitution of an email address, coz' you'd would NEVER get '^' and '.'. Anyway, maybe it makes sense to some to look for incorrectly rot13'd email-addresses, but why not catch the correctly rot13'd also? /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
On Thu, May 31, 2007 at 06:06:54PM +0200, Per Jessen wrote:
> Then why is the pattern very specific wrt '^' and '(' ?
Tries to match common substitutions for @ and . ?
> Not really. A rot13 of an email-address should not substitute '@'
> and '.'.
Again, don't think of rot13 specifically. Single substition cipher.
--
Randomly Selected Tagline:
"The only way you'll get me to talk is through slow painful torture, and I
don't think you've got the grapes." - Stewie on Family Guy
pgp4WsJkxWcu6.pgp
Description: PGP signature
Re: OBSCURED_EMAIL ?
Theo Van Dinter wrote:
> On Thu, May 31, 2007 at 09:46:56AM +0200, Per Jessen wrote:
>> I've been looking at what a rot13'ed email-address looks like, and it
>> doesn't come close to matching the pattern above.
>
> rot13 is a common/well-defined version of a single substitution
> cipher. This rule tries to match those, not the rot13 a-m <-> n-z
> mapping specifically.
Then why is the pattern very specific wrt '^' and '(' ?
>> This would patch the pattern above: "ghtyetrt^rt456yu78ui(tyy "
>
> Right, and that looks like [EMAIL PROTECTED] after going through
> a substitution.
Not really. A rot13 of an email-address should not substitute '@'
and '.'.
> Check out the list archives, this came up a while ago.
OK, will do.
/Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
On Thu, May 31, 2007 at 09:46:56AM +0200, Per Jessen wrote:
> I've been looking at what a rot13'ed email-address looks like, and it
> doesn't come close to matching the pattern above.
rot13 is a common/well-defined version of a single substitution cipher. This
rule tries to match those, not the rot13 a-m <-> n-z mapping specifically.
> This would patch the pattern above: "ghtyetrt^rt456yu78ui(tyy "
Right, and that looks like [EMAIL PROTECTED] after going through
a substitution. Check out the list archives, this came up a while ago.
--
Randomly Selected Tagline:
sub eval_C ($proggie) { CGrammar.top($proggie).compile.link.run.dump.gdb }
-- Larry Wall in <[EMAIL PROTECTED]>
pgpwf3urESar8.pgp
Description: PGP signature
Re: OBSCURED_EMAIL ?
Matthias Haegele wrote: >> Yep, that should work - I'll have to obscure the attachments too though: >> >> http://jessen.ch/files/problem-with-missing-content-type2 > > > scnr: > War ja klar dass sowas (Müll) nur nur aus irgendeiner Besprechung kommen > kann ;-). Matthias, FYI, I can't reply to you directly - your mail-server is rejecting all emails from "computer.org". (due to rfc-ignorant). /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
On Thu, May 31, 2007 at 09:46:56AM +0200, Per Jessen wrote: > I've got a couple of FPs that all got 1.6points from OBSCURED_EMAIL - Just out of interest, I lowered the score on this one because it hits TeX formulas, such as ab^c(def) The last thing I want to do is annoy the few people who use real typesetting software. ;-) Matthew -- Matthew Newton <[EMAIL PROTECTED]> Network Support and UNIX Systems Administrator, Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <[EMAIL PROTECTED]>
Re: OBSCURED_EMAIL ?
Justin Mason wrote: >> The problem seems to be that it contains 4 attached JPEGs which have >> been attached without the proper MIME-type: >> >> Content-Type: ; name=PICT0089.JPG >> >> It looks like spamassassin decides to scan the binary content of the >> jpegs as body text which is perhaps why it comes up with these >> obscure hits. > > is that (a) valid MIME and/or (b) supported by any common MUA? a) most probably not. b) Thunderbird recognises the attachments, but tries to display them as text. Which is probably a reasonable behaviour, although it's hardly "supported". > if you could generate a new mail that displays the same issue, > and can be shared, that would be helpful. See previous post. /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Matthias Haegele wrote: > Per Jessen schrieb: >> Matthias Haegele wrote: >> >>> Not seen it here ... >>> Perhaps you could paste the mail somewhere and send the link to the >>> list? >> >> Not a bad idea, except it's a customer email, so that's pretty much >> out of the question ... > > So why not "overwrite" the confidential part and then paste it? Yep, that should work - I'll have to obscure the attachments too though: http://jessen.ch/files/problem-with-missing-content-type2 /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Per Jessen writes: > Matthias Haegele wrote: > > > Not seen it here ... > > Perhaps you could paste the mail somewhere and send the link to the list? > > Not a bad idea, except it's a customer email, so that's pretty much out > of the question ... > > The problem seems to be that it contains 4 attached JPEGs which have > been attached without the proper MIME-type: > > Content-Type: ; name=PICT0089.JPG > > It looks like spamassassin decides to scan the binary content of the > jpegs as body text which is perhaps why it comes up with these obscure > hits. is that (a) valid MIME and/or (b) supported by any common MUA? if you could generate a new mail that displays the same issue, and can be shared, that would be helpful. --j.
Re: OBSCURED_EMAIL ?
Per Jessen schrieb: Matthias Haegele wrote: Not seen it here ... Perhaps you could paste the mail somewhere and send the link to the list? Not a bad idea, except it's a customer email, so that's pretty much out of the question ... So why not "overwrite" the confidential part and then paste it? The problem seems to be that it contains 4 attached JPEGs which have been attached without the proper MIME-type: Content-Type: ; name=PICT0089.JPG It looks like spamassassin decides to scan the binary content of the jpegs as body text which is perhaps why it comes up with these obscure hits. /Per Jessen, Zürich -- Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: OBSCURED_EMAIL ?
Matthias Haegele wrote: > Not seen it here ... > Perhaps you could paste the mail somewhere and send the link to the list? Not a bad idea, except it's a customer email, so that's pretty much out of the question ... The problem seems to be that it contains 4 attached JPEGs which have been attached without the proper MIME-type: Content-Type: ; name=PICT0089.JPG It looks like spamassassin decides to scan the binary content of the jpegs as body text which is perhaps why it comes up with these obscure hits. /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Per Jessen wrote:
> I've got a couple of FPs that all got 1.6points from OBSCURED_EMAIL -
>
> body OBSCURED_EMAIL /\w+\^\S+\(\w{2,4}\b/
> describe OBSCURED_EMAIL Message seems to contain rot13ed address
>
I was having a closer look, and I couldn't even find a '^' character
anywhere - till I realised that the email contained 4 JPEGs as
attachment, but with
Content-Type: ; name=PICT0089.JPG
I.e. no MIME-type provided. I'm guessing that spamassassin decided to
scan those attachments as if they were body text, and then found
something or other weird in the JPEG.
Has anyone else come across this?
/Per Jessen, Zürich
OBSCURED_EMAIL ?
I've got a couple of FPs that all got 1.6points from OBSCURED_EMAIL -
body OBSCURED_EMAIL /\w+\^\S+\(\w{2,4}\b/
describe OBSCURED_EMAIL Message seems to contain rot13ed address
I've been looking at what a rot13'ed email-address looks like, and it
doesn't come close to matching the pattern above.
This would patch the pattern above: "ghtyetrt^rt456yu78ui(tyy ", but
after rot13, it still doesn't look like an email address:
"tuglrgeg^eg456lh78hv(gll"
My email-address | rot13 = "[EMAIL PROTECTED]"
/Per Jessen, Zürich
