[no subject]
Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code EU 2024 are now open! We will be supporting Community over Code EU, Bratislava, Slovakia, June 3th - 5th, 2024. TAC exists to help those that would like to attend Community over Code events, but are unable to do so for financial reasons. For more info on this years applications and qualifying criteria, please visit the TAC website at < https://tac.apache.org/ >. Applications are already open on https://tac-apply.apache.org/, so don't delay! The Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend the full event. Important: Applications close on Friday, March 1st, 2024. Applicants have until the the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful applications shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. For those that will need a Visa to enter the Country - we advise you apply now so that you have enough time in case of interview delays. So do not wait until you know if you have been accepted or not. We look forward to greeting many of you in Bratislava, Slovakia in June, 2024! Kind Regards, Gavin (On behalf of the Travel Assistance Committee)
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Hmmm... I think I'm close here! Thanks for the tip about procmail, and I was delighted to find that my system not only has procmail already installed but there was even an active - APPARENTLY active! - ~/.procmailrc ... that even already had Spam Assassin setup in it?! Nice! Here's what ha(d/s): ## #:0fw #| /usr/bin/spamassassin :0 * ^X-Spam-Status: *Yes * ^X-DSPAM-Result: *!Innocent $HOME/mail/spam/ ## Well... The only thing I want a tiny bit different there is to send it to Spam instead of spam, because I want to use one of them for confirmed spam, for possible future training, and the other for suspected spam. However, it's not actually doing anything at present... Can someone save me from reading a heck of a lot of the docs to find out how to configure this in WITHOUT creating a problem for using Dovecot, too? ...We DO need Dovecot, it's just not authenticating the imap connections properly and I just don't have time right now to focus on it. Parking the damned spam somehow is a great help. And, this is perhaps BETTER than gettting the subject line rewrite working again because it'll be automagically moved for folks! Win! Thanks much, Richard
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
h-blah-blah... sorry for the digression. The reason for posting is ultimately that the above denoted directive was working fine as I was trying to rebuild things - namely: rewrite_header Subject [SPAM] But at some point as I made some edits, SA continues to work, and honors everything else in the file so far as I have noted so far - such as required hits, which is directly above it - but the subject is no longer "rewritten" to include the above noted label. Date: Wed, 1 Mar 2023 09:03:44 +0100 From: Reindl Harald from 2014: spamass-milter[14891]: Could not extract score from seek for "add_header all Status" - changes here may result in some milter or other software processing the message can't parse it Thanks: I get "Pattern not found: add_header" from vim. And nothing else should be editing a thing - it's either accept or reject! Date: Wed, 01 Mar 2023 01:01:05 -0500 From: Bill Cole The critical missing fact: what mechanism do you use to integrate SA into mail delivery? In some cases (e.g. MIMEDefang) the 'glue' layer actually handles header modification. In other cases, the glue may explicitly load its own config files and/or run as a special user with a bespoke user_prefs file. We've just let the headers get marked - and subject lines - and leave it to the mail clients, such as Thunderbird, which many of our system's users like. ... That is, Postfix delivers as usual. People have come to depend on it (because we don't move it to an alternative "folder" for them) so... Presuming this is NOT the place, where do I find help? Date: Wed, 01 Mar 2023 01:01:05 -0500 From: Bill Cole If 'perldoc Mail::SpamAssassin::Conf' and searches of the wiki and list archives don't answer a question, this is the best place to come for help. No one can guarantee that you find a solution here, but it's the best place to look. Thanks! Or, if someone just recognizes this, please do reply! All input welcome, thanks. I'd never bothered to try before, but since I'm here and you have the background, and I know it's slightly off topic: Is there an easy solution to delivering / moving spam to a specific "folder" not involving Dovecot on a Fedora / Postfix system? Date: Wed, 01 Mar 2023 01:01:05 -0500 From: Bill Cole SA knows nothing about mail delivery. Yes, of course, and that's why I acknowledged up front that this was off topic. Any solution has to be specific to whatever mechanism you use to access delivered mail, i.e. your IMAP server or a local MUA or ???. If you have an IMAP server other than Dovecot, it probably has a documented mechanism for non-INBOX delivery which you will need to use. Consult the docs for whatever you use. We use Dovecot but are having post rebuild difficulties with it and our imap is therefore not working ATM... We're working on it, but meanwhile, people can log in the old fashioned way and read their mail. Date: Wed, 01 Mar 2023 01:01:05 -0500 From: Bill Cole If your mailstore uses mbox or Maildir, the unmaintained antique software named "procmail" could be used for delivery. As an antique myself, I use it, but I cannot in good conscience recommend anyone else adopt it de novo. Date: Wed, 1 Mar 2023 08:52:10 +0100 From: David Bürgin It looks like procmail is maintained again, by the original author even (with interesting background on the procmail code, too): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24 HEY, I remember procmail! AND, I didn't have to do anything: procmail-3.22-57.fc37.x86_64 is already installed - via being Fedora Server, I guess?! Not sure, but OK, I can try it! Date: Wed, 01 Mar 2023 09:22:29 -0500 From: Bill Cole I rescind my warning. That is very good news, as there is nothing that quite replaces it. Translating my personal .procmailrc to Sieve has been on my 'to do' list for longer than I've used SpamAssassin. Also very good news there from the author that he has integrated most of the Debian patches and fixed all of the bug backlog. HEY, Impressive! Let's hear it for an obvious old timer still in the game, producing useful stuff for folks!... I like to think of myself in that category, landing my first job in computing in 1977 at the age of 14! But I digress, sorry. My man page says: AUTHORS Stephen R. van den Berg Philip A. Guenther ...I'll have a cocktail and toast them later this afternoon! Thanks for all replies, Richard -- Richard Troy
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
On 2023-03-01 at 02:52:10 UTC-0500 (Wed, 1 Mar 2023 08:52:10 +0100) David Bürgin is rumored to have said: Bill Cole: If your mailstore uses mbox or Maildir, the unmaintained antique software named "procmail" could be used for delivery. As an antique myself, I use it, but I cannot in good conscience recommend anyone else adopt it de novo. It looks like procmail is maintained again, by the original author even (with interesting background on the procmail code, too): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24 I rescind my warning. That is very good news, as there is nothing that quite replaces it. Translating my personal .procmailrc to Sieve has been on my 'to do' list for longer than I've used SpamAssassin. Also very good news there from the author that he has integrated most of the Debian patches and fixed all of the bug backlog. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Bill Cole: > If your mailstore uses mbox or Maildir, the unmaintained antique software > named "procmail" could be used for delivery. As an antique myself, I use it, > but I cannot in good conscience recommend anyone else adopt it de novo. It looks like procmail is maintained again, by the original author even (with interesting background on the procmail code, too): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
On 2023-02-28 at 22:46:54 UTC-0500 (Tue, 28 Feb 2023 19:46:54 -0800 (PST)) Richard Troy is rumored to have said: Hi All, I've been subscribed for ... close to 15 years, I think? Heck, 20 is maybe possible! ... Just reading I have learned a hell of a lot, thanks to this community, but have never posted before. Now's the time, though, because I really need some help and am not sure where to look for it. (I've already done the basic searches - if I've missed something, I apologize.) Very recently our entire /var tree got wiped out due to a bug in a backup script someone was testing, and not only on our primary system but also on our alternate (backup) system too. Ouch! We've had to do a complete rebuild and apply what we can from backups. We have pretty good backups, mostly, but on /var? Well, you learn how good your backups are when you have a disaster just like this! And, it turns out, we didn't have a recent local.cf (or, for that matter a lot more). (We now backup /var and EVERYTHING in /! ... Good advice, now that disk space is dirt cheap!) What was local.cf doing on /var? The standard location is in /etc/mail/spamassassin/. The reason for posting is ultimately that the above denoted directive was working fine as I was trying to rebuild things - namely: rewrite_header Subject [SPAM] But at some point as I made some edits, SA continues to work, and honors everything else in the file so far as I have noted so far - such as required hits, which is directly above it - but the subject is no longer "rewritten" to include the above noted label. The critical missing fact: what mechanism do you use to integrate SA into mail delivery? In some cases (e.g. MIMEDefang) the 'glue' layer actually handles header modification. In other cases, the glue may explicitly load its own config files and/or run as a special user with a bespoke user_prefs file. People have come to depend on it (because we don't move it to an alternative "folder" for them) so... Presuming this is NOT the place, where do I find help? If 'perldoc Mail::SpamAssassin::Conf' and searches of the wiki and list archives don't answer a question, this is the best place to come for help. No one can guarantee that you find a solution here, but it's the best place to look. Or, if someone just recognizes this, please do reply! All input welcome, thanks. I'd never bothered to try before, but since I'm here and you have the background, and I know it's slightly off topic: Is there an easy solution to delivering / moving spam to a specific "folder" not involving Dovecot on a Fedora / Postfix system? SA knows nothing about mail delivery. Postfix only knows a few ways to deliver mail, none of which involve delivering one recipient's mail to multiple different places based on content. Any solution has to be specific to whatever mechanism you use to access delivered mail, i.e. your IMAP server or a local MUA or ???. If you have an IMAP server other than Dovecot, it probably has a documented mechanism for non-INBOX delivery which you will need to use. Consult the docs for whatever you use. If your mailstore uses mbox or Maildir, the unmaintained antique software named "procmail" could be used for delivery. As an antique myself, I use it, but I cannot in good conscience recommend anyone else adopt it de novo. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
The rewrite_header Subject [SPAM] directive has stopped working?!
Hi All, I've been subscribed for ... close to 15 years, I think? Heck, 20 is maybe possible! ... Just reading I have learned a hell of a lot, thanks to this community, but have never posted before. Now's the time, though, because I really need some help and am not sure where to look for it. (I've already done the basic searches - if I've missed something, I apologize.) Very recently our entire /var tree got wiped out due to a bug in a backup script someone was testing, and not only on our primary system but also on our alternate (backup) system too. Ouch! We've had to do a complete rebuild and apply what we can from backups. We have pretty good backups, mostly, but on /var? Well, you learn how good your backups are when you have a disaster just like this! And, it turns out, we didn't have a recent local.cf (or, for that matter a lot more). (We now backup /var and EVERYTHING in /! ... Good advice, now that disk space is dirt cheap!) The reason for posting is ultimately that the above denoted directive was working fine as I was trying to rebuild things - namely: rewrite_header Subject [SPAM] But at some point as I made some edits, SA continues to work, and honors everything else in the file so far as I have noted so far - such as required hits, which is directly above it - but the subject is no longer "rewritten" to include the above noted label. People have come to depend on it (because we don't move it to an alternative "folder" for them) so... Presuming this is NOT the place, where do I find help? Or, if someone just recognizes this, please do reply! All input welcome, thanks. I'd never bothered to try before, but since I'm here and you have the background, and I know it's slightly off topic: Is there an easy solution to delivering / moving spam to a specific "folder" not involving Dovecot on a Fedora / Postfix system? I know I could pull it off by directing all pre-mailbox delivery to a script I write myself (via the .forward mechanism if necessary), but I just don't have the time! Private replies welcome! Regards ... and thanks to the list for all the great and useful materials - just wish I could absorb it all! (I'm now trying to relearn years worth of stuff I've forgotten because I don't use it often enough! I only run this one site's systems as an SA!) Richard -- Richard Troy
Re: spam subject marking
On 11/17/22 9:00 AM, Bill Cole wrote: Easier said than done. It's actually quite easy to do. But most people don't want to do what I think should be done. IMHO, the email list itself is a 1st class / proper entity that you are emailing or reading email from. -- I'm not emailing Bill or Greg or Marc or any specific individual when I type this reply. Treat the mailing list as an individual that receives / reads / types / sends email messages. The mailing list is an SMTP terminal point. It is the end exclusive or the start of a message. The new messages that it generates may be substantially based on content in messages that it received. But that's still a new message. As such, messages from the mailing list should reflect the mailing list and not pretend or lie or fudge or fake that they are anyone else. But that's my opinion and it's an unpopular one. But it's also one that is completely 100% compatible with SPF / DKIM / DMARC / etc. (Assuming that the mailing list / it's MTA apply said security to the new messages that it originates.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: spam subject marking
On 2022-11-16 at 06:46:57 UTC-0500 (Wed, 16 Nov 2022 06:46:57 -0500) Greg Troxel is rumored to have said: > Not really this topic, but I think mailing lists really need to be set > up to not break DKIM. Easier said than done. I'm on an absurd number of mailing lists, and MOST are not entirely DKIM-safe. I have not seen this list or any other ASF list break DKIM but I have not checked rigorously. A similar example is the Postfix-Users list, which very occasionally does some necessary restructuring of mail, breaking signatures. I suspect similar corner cases exist here: e.g. mail arriving with 8-bit encoding may cause a re-encode. Obviously, any list that adds tags to Subject, munges From, forces or deletes Reply-To, or reflows text (rare, but it happens...) will clobber DKIM. Some sites "oversign" headers that lists should be adding (the whole List-* zoo) which basically is a footbullet. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire signature.asc Description: OpenPGP digital signature
Re: spam subject marking
On 2022-11-15 at 15:16:49 UTC-0500 (Tue, 15 Nov 2022 20:16:49 +) Marc is rumored to have said: >> You might want to point out to them that rewrite_header breaks any DKIM >> signature on mail, > > Hmmm, good point, not really thought about this even. Are email clients > complaining about this? > >> in addition to cluttering the Subject if >> misclassified mail is part of a conversation. > > So the alternative is adding a header and move it to the spam folder > automatically on the basis of the header? Yeah, you CAN do that. I just reject anything deemed spam outright. That way, false positives (which are extremely bad and should not be quiet) are never silent due to my systems' behavior. The sending MTA gets an explicit 5xx reply and should be transmitting that back to the human sender as a DSN, so they can try to fix the problem. Dropping suspected spam into a "spam folder" just gives for wanted mail a new place to die unseen. (That's just my personal opinion, not a policy of the SA PMC, which doesn't take any positions on how individual sites apply SA results.) > Currently I just want to 'warn' users that the message is possible spam, they > can decide to move such emails automatically to a spam folder by enabling a > sieve rule. > What would be an alternative method to keep such functionality without > altering the subject? Use SA's "add_header" feature. It is on by default, but depending on which 'glue' you use to integrate SA and which distribution package you use you may not be seeing the modification by add_header. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: spam subject marking
On 2022-11-15 at 21:45:52 UTC-0500 (Tue, 15 Nov 2022 18:45:52 -0800) Loren Wilton is rumored to have said: >> So the alternative is adding a header and move it to the spam folder >> automatically on the basis of the header? >> >> Currently I just want to 'warn' users that the message is possible spam, >> they can decide to move such emails automatically to a spam folder by >> enabling a sieve rule. >> What would be an alternative method to keep such functionality without >> altering the subject? > > If SA sees the message and classifies it as spam, it normally adds (from an > example) > X-Spam-Flag: YES > X-Spam-Level: > X-Spam-Status: Yes, score=8.2 required=5.0 tests=BAYES_50=0.8,DKIM_SIGNED=0.1, > > It should be trivial to look for the "X-Spam-Flag: YES" line. Calling the addition of those headers "normal" is a possibly a bit misleading. Such configuration is *common* but is an entirely local choice. There are 4 'add_header' directives in the default prefs distributed in the rules package. However, many sites use configurations that DO NOT add any headers or 'glue' that ignores the message modifications and may or may not add similar headers (e.g. milters that embed SA rather than use a separate spamc.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: spam subject marking
On 2022-11-16 at 08:01:12 UTC-0500 (Wed, 16 Nov 2022 06:01:12 -0700) Grant Taylor via users is rumored to have said: > Or said another way, DKIM is only supposed to be a /positive/ /assertion/ if > / when a DKIM signature validation passes. DKIM is supposed to not be > negative. That's ABSOLUTELY CORRECT. DKIM is known to be fragile in transit. It has ALWAYS been known to be fragile in transit. If you want a signature for repudiation purposes, you need *at least* DMARC on top or some other more robust signing mechanism. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire signature.asc Description: OpenPGP digital signature
Re: spam subject marking
On 11/16/22 4:46 AM, Greg Troxel wrote: Can you expand on that? I'll try. My understanding is that few MUAs test DKIM signatures /client/ /side/. -- The only exception that I'm aware of is that there was a Thunderbird add-on that would test DKIM signatures /client/ /side/. Almost all DKIM /testing/ / /checking/ that I'm aware of is /receiving/ MTA side. A DKIM failure means that one can't establish that the message came from the domain, and this leads to: Sure. decline to apply whitelist_from_dkim perhaps, if one has data that most things with that From: have valid dkim sigs, give it some spam points. My understanding is that /per/ /RFCs/ a failing DKIM signature is to be treated the same as if there is no DKIM signature. Or said another way, DKIM is only supposed to be a /positive/ /assertion/ if / when a DKIM signature validation passes. DKIM is supposed to not be negative. Please correct me if I'm wrong. in spam filtering and if there is a DMARC policy, and it fails SPF also, file as spam or reject N.B. DMARC is vastly different from, but still potentially reliant upon DKIM. Are you saying tht some MTAs outright reject on DKIM failure, in the absence of DMARC? I have seen evidence of postmasters /mis/configuring their MTAs to behave the /opposite/ /of/ /what/ /RFCs/ /prescribe/. I did just get a bounce message in reply to a message I sent here, complaining that my message failed DKIM (maybe the list munged it) and SPF (ok; the list is not in general authorized to send mail from my domain) and therefore was being rejected (but I do not currently publish a DMARC policy). I'm not getting on my what mailing list managers should and should not do horse in this email. ;-) Not really this topic, but I think mailing lists really need to be set up to not break DKIM. TL;DR: I believe that mailing list managers are an email terminus; end of my message and the start of a new message substantively based on my message. The kids all want us to use forums anyway, It's healthy to want things. It's an indication that you have opinions and are not a sheepeople. and DKIM-breaking and spam filtering issues, really doesn't help. I've found that when both email terminus (termini?) behave properly, DKIM is not an issue. At worst, a failing DKIM signature is treated as if the DKIM signature doesn't exist. At best, a passing DKIM signature adds credence to a message / it's source. Agreed. Really the MUA needs support for a spam-marking header, or to file messages with such headers into a separate mailbox/folder/whatever. I would assume that any contemporary MUA worth it's disk space does, and has for 10-15 years, understands various spam filter headers asserting status. E.g. Thunderbird has built in support for SpamAssassin, Bogofilter, DSPAM, POPFile, and SpamPal. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: spam subject marking
Greg Troxel writes: > I did just get a bounce message in reply to a message I sent here, > complaining that my message failed DKIM (maybe the list munged it) and > SPF (ok; the list is not in general authorized to send mail from my > domain) and therefore was being rejected (but I do not currently publish > a DMARC policy). Update: my messages to the list, as I received them, both this one and the one that provoked the bounce, have valid DKIM signatures as determined by inbound processing on my MTA. So while my rant about DKIM and lists stands in general, I apologize for casting aspersions on this list: it appears to be working well as far as not breaking DKIM, at least for senders without DMARC. signature.asc Description: PGP signature
Re: spam subject marking
"Grant Taylor via users" writes: > On 11/15/22 1:16 PM, Marc wrote: >> Hmmm, good point, not really thought about this even. Are email >> clients complaining about this? > > Few email clients are testing DKIM. Some servers are testing > DKIM. Some systems are mis-treating DKIM failure as something more > sever than the specification allows. Can you expand on that? A DKIM failure means that one can't establish that the message came from the domain, and this leads to: decline to apply whitelist_from_dkim perhaps, if one has data that most things with that From: have valid dkim sigs, give it some spam points. in spam filtering and if there is a DMARC policy, and it fails SPF also, file as spam or reject Are you saying tht some MTAs outright reject on DKIM failure, in the absence of DMARC? I did just get a bounce message in reply to a message I sent here, complaining that my message failed DKIM (maybe the list munged it) and SPF (ok; the list is not in general authorized to send mail from my domain) and therefore was being rejected (but I do not currently publish a DMARC policy). Not really this topic, but I think mailing lists really need to be set up to not break DKIM. The kids all want us to use forums anyway, and DKIM-breaking and spam filtering issues, really doesn't help. >> Currently I just want to 'warn' users that the message is possible >> spam, they can decide to move such emails automatically to a spam >> folder by enabling a sieve rule. > > I suspect any visible modification you make to the message will also > likely break DKIM in the same way. Agreed. Really the MUA needs support for a spam-marking header, or to file messages with such headers into a separate mailbox/folder/whatever. >> What would be an alternative method to keep such functionality >> without altering the subject? > > Adding headers is the most common thing that I see. Then let the > email client decide what action, if any, to take based on that > header's contents. me too signature.asc Description: PGP signature
Re: spam subject marking
On Tue, Nov 15, 2022 at 9:46 PM Loren Wilton wrote: > > If SA sees the message and classifies it as spam, it normally adds (from > an > example) > X-Spam-Flag: YES > X-Spam-Level: > X-Spam-Status: Yes, score=8.2 required=5.0 > tests=BAYES_50=0.8,DKIM_SIGNED=0.1, > > It should be trivial to look for the "X-Spam-Flag: YES" line. > > And most mail clients and platforms let you key off of this for redirecting email to a spam folder.
Re: spam subject marking
So the alternative is adding a header and move it to the spam folder automatically on the basis of the header? Currently I just want to 'warn' users that the message is possible spam, they can decide to move such emails automatically to a spam folder by enabling a sieve rule. What would be an alternative method to keep such functionality without altering the subject? If SA sees the message and classifies it as spam, it normally adds (from an example) X-Spam-Flag: YES X-Spam-Level: X-Spam-Status: Yes, score=8.2 required=5.0 tests=BAYES_50=0.8,DKIM_SIGNED=0.1, It should be trivial to look for the "X-Spam-Flag: YES" line.
Re: spam subject marking
On 11/15/22 1:16 PM, Marc wrote: Hmmm, good point, not really thought about this even. Are email clients complaining about this? Few email clients are testing DKIM. Some servers are testing DKIM. Some systems are mis-treating DKIM failure as something more sever than the specification allows. So the alternative is adding a header and move it to the spam folder automatically on the basis of the header? Adding the header, yes. Altering where the message is delivered is completely independent and outside of SpamAssassin purview. Currently I just want to 'warn' users that the message is possible spam, they can decide to move such emails automatically to a spam folder by enabling a sieve rule. I suspect any visible modification you make to the message will also likely break DKIM in the same way. You can attach the unmodified message to a wrapper message, and add whatever text you want in the wrapper message. This is an exercise left up to the reader. ;-) What would be an alternative method to keep such functionality without altering the subject? Adding headers is the most common thing that I see. Then let the email client decide what action, if any, to take based on that header's contents. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
RE: spam subject marking
> You might want to point out to them that rewrite_header breaks any DKIM > signature on mail, Hmmm, good point, not really thought about this even. Are email clients complaining about this? > in addition to cluttering the Subject if > misclassified mail is part of a conversation. So the alternative is adding a header and move it to the spam folder automatically on the basis of the header? Currently I just want to 'warn' users that the message is possible spam, they can decide to move such emails automatically to a spam folder by enabling a sieve rule. What would be an alternative method to keep such functionality without altering the subject?
Re: spam subject marking
On 2022-11-15 at 05:04:08 UTC-0500 (Tue, 15 Nov 2022 10:04:08 +) Marc is rumored to have said: > I am having repeated occurances of ***SPAM*** in the subject, maybe it is > good to stop adding ***SPAM*** if there are already 10 in the subject? That's an entirely local choice, controlled by the rewrite_header config parameter. It is NOT enabled by default. Talk to whoever is adding that to your mail. You might want to point out to them that rewrite_header breaks any DKIM signature on mail, in addition to cluttering the Subject if misclassified mail is part of a conversation. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: spam subject marking
Apache SpamAssassin it's both an API and a program. In my installation, I do not use it to do any subject modifications and I use a milter called mime defang to do that using my own logic. You can also configure spam d/Spam seed not to modify the subject. If you would like similar headings removed from spams though why email is getting multiple would be a question, patches are welcome for consideration. Regards, KAM On Tue, Nov 15, 2022, 07:01 Marc wrote: > > > > When a *user* replies it's not at the beginning > > it's "Re: **spam**" > > :) Indeed, and in other languages it is even different, but I think > developers get the point ;) >
RE: spam subject marking
> > When a *user* replies it's not at the beginning > it's "Re: **spam**" :) Indeed, and in other languages it is even different, but I think developers get the point ;)
RE: spam subject marking
> >> spamassassin add multiple times '**spam**' to the subject. > >> > >> your spamassassin only adds it one time > > > > Yes I know, and lazy users do not remove it in replies, that is how > you get multiple occurances > > than it's "Subject: **spam** Re: **spam**" and the only relevant > information for you is the first because that's from your system modifications to the subject I see only as relevant to the recipient. Email users really don't have a clue what is added by whom. Users that leave our spam marked subject in the email replies, generate even issues why other people are receiving their email marked as spam. > just because on a random place in the middle of the subject **spam** > appears musn't supress the flagging of my own filter Indeed that is why a solution for development could be something like if spam check if there is in the beginning of the subject a string that matches the 'rewrite_header' as configured in local.cf, if not add, if it is there skip. I think the situation I am describing is quite often occurring. I wonder what others think of this.
RE: spam subject marking
> >> > >> multiple signs of spam leading to marking a message as spam > > > > This is not relevant for the discussion on whether or not to have > spamassassin add multiple times '**spam**' to the subject. > > your spamassassin only adds it one time Yes I know, and lazy users do not remove it in replies, that is how you get multiple occurances.
RE: spam subject marking
> > Am 15.11.22 um 11:48 schrieb Marc: > >> > >> and i told you that it's useful when a message already passed > multiple > >> hops which flagged it as spam to outright reject it > >> > >> /^Subject: .*\*\*\*\*\*spam\*\*\*\*\* \*\*\*\*\*spam\*\*\*\*\*/ > REJECT > >> Administrative Prohibition (Subject) > > > > A message is either spam or not > > that's not how spam filtering works > > multiple signs of spam leading to marking a message as spam This is not relevant for the discussion on whether or not to have spamassassin add multiple times '**spam**' to the subject. > > and is marked as spam or not > > good filters don't only mark messages but reject them > > > I don't see how telling me 3 times it is spam has any relevance. > > how comes that you don't see the relevance of the sending system already > thought it was spam and instead jerect it still continued to send the > trash out? This is not relevant for the discussion on whether or not to have spamassassin add multiple times '**spam**' to the subject. > > If you value the information created by multiple servers processing > the message, then this information should be passed differently > > and how do you imagine that in a cahin of indepdenent systems? My first thought would be by adding headers. If I had a chain of 3 servers processing a message by spamassassin. The first 2 would only add scores in the header and the last one would do the calculation upon which is decided to have the message visibly marked as spam for the recipient.
RE: spam subject marking
> > and i told you that it's useful when a message already passed multiple > hops which flagged it as spam to outright reject it > > /^Subject: .*\*\*\*\*\*spam\*\*\*\*\* \*\*\*\*\*spam\*\*\*\*\*/ REJECT > Administrative Prohibition (Subject) A message is either spam or not, and is marked as spam or not. I don't see how telling me 3 times it is spam has any relevance. If you value the information created by multiple servers processing the message, then this information should be passed differently.
RE: spam subject marking
> > > > I am having repeated occurances of ***SPAM*** in the subject, maybe it > is good to stop adding ***SPAM*** if there are already 10 in the > subject? > > ask the sending admin why in the world he still continues to blow out > that crap instead trash it > > if there are already two in the subject i reject them with postfix > header rules What are you on about? This is for the developers to re-think their design if it is necessary to keep adding SPAM
spam subject marking
I am having repeated occurances of ***SPAM*** in the subject, maybe it is good to stop adding ***SPAM*** if there are already 10 in the subject?
[no subject]
Good question... probably an interesting new feature for SA: dividing and deal with attached emails (and nested emails that look like a chat) in a one by one basis... Pete. >On Tuesday, April 26, 2022, 02:36:25 PM GMT+2, Matus UHLAR - fantomas wrote: >Hello, >is it possible to match message headers in rfc822 atttachments? >from what I know, "header" rules only apply to mail headers and mimeheader >only apply to mime headers. >body and rawbody afaik only search in bodies of messages or included messages. >I have asked some time ago but no success: >https://marc.info/?l=spamassassin-users=132282473328809=2 >is this possible now or do we need out-of SA solution for this? >-- >Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ >Warning: I wish NOT to receive e-mail advertising to this address. >Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. >Fighting for peace is like fucking for virginity...
[no subject]
Hello, is it possible to match message headers in rfc822 atttachments? from what I know, "header" rules only apply to mail headers and mimeheader only apply to mime headers. body and rawbody afaik only search in bodies of messages or included messages. I have asked some time ago but no success: https://marc.info/?l=spamassassin-users=132282473328809=2 is this possible now or do we need out-of SA solution for this? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity...
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 19:39:06 +0100
RW wrote:
>
> /\xF0\x9F(?:\x98[\x80-\xBF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xBF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/
This includes the block mentioned by Bill Cole and and is simplified a
bit
/\xF0\x9F[\x98-\x99\xA4-\xA7\x8C-\x97][\x80-\x8F]|\xE2\x98[\xB9-\xBB]/
However, if you don't expect to get any legitimate mail with Asian
languages in the subject, you can probably get away with including all
4-byte UTF-8. Those code points are dominated by CJK, symbols, emojis
and dead languages.
/[\xF0-\xF7][\x80-\xBF]{3}|\xE2\x98[\xB9-\xBB]/
Re: Detect Emoticons in Subject
On Fri, May 21, 2021 at 09:53:36AM +0200, Tom Hendrikx wrote: > > Can someone explain why SA cannot support this type of syntax, or what would > be needed to get it supported? IMHO it makes it a lot easier for end-users > to understand a rule, and for rule developers to write or even contribute > new UTF-8-related rules, so it might be worth the effort to get it > supported? Perl strings internally would have to be UTF8. Mandatory prerequisite would be normalize_charset 1 in SA. Could be some cases where SA can't decode mails properly to UTF8, so it's a question mark what happens then. Some changes are coming already in 4.0, for example normalize_charset 1 will be default. But more complex internal/rule changes require a lot of thought on how to maintain backwards compatibility. I'm sure some people will still run 3.4 for years to come. Sorry to say but there are too few developers right now. It's up to the community to pick up the pace.
Re: Detect Emoticons in Subject
On 20-05-2021 18:19, RW wrote:
On Thu, 20 May 2021 11:42:59 -0400
Clive Jacques wrote:
Hi,
I've been using SA a long time. Lately, I'm getting more and more
spam with emoticons in the subject line. I'd say about 90% of my
emails with emoticons in the subject are spam. I'd like to create a
local rule which scores email with emoticons in the subject.
# Local Rule for Emoticons in subject
subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
The rule should start with "header", that's what's causing the lint
failure.
However, AFAIK, the rule still won't work because \p{Emoticons}
isn't supported in spamassassin, which works on byte sequences. You
need to rewrite it to match UTF-8 bytes.
I'm not a real fan of very complex regular expressions, as they tend to
get hard to read/understand very quickly. This thread is a perfect
example: the syntax that the OP proposed (/\p{Emoticons}/) seems
perfectly readable, and all the actually working alternatives are, with
all respect to the authors, a nightmare to decipher. Especially for
users not really proficient in regular expressions, the OP's syntax is
perfectly understandable and all the alternatives aren't.
I'm not really into the regex engine of perl/SA, so please correct if
I'm wrong. The /\p{Emoticons}/ syntax seems to me a builtin feature of
the regex spec/perl (as opposed to pseudo-code, displaying something
that actually doesn't exist).
Can someone explain why SA cannot support this type of syntax, or what
would be needed to get it supported? IMHO it makes it a lot easier for
end-users to understand a rule, and for rule developers to write or even
contribute new UTF-8-related rules, so it might be worth the effort to
get it supported?
Thanks in advance,
Tom
Re: Detect Emoticons in Subject: CHAOS
On 2021-05-20 22:33, Clive Jacques wrote: Here is a good example of such an email (attached, stripped of identifying info). This attachment is suspicious because its type doesn't match the type declared in the message. If you do not trust the sender, you shouldn't open it in the browser because it may contain malicious contents. Expected: text/plain (.txt); found: message/rfc822 (.eml) should i ignore roundcube warnings ? :)
Re: Detect Emoticons in Subject: CHAOS
On Thu, 20 May 2021 15:35:21 -0400
Jared Hall wrote:
> Clive Jacques wrote:
> > # Local Rule for Emoticons in subject
> > subject EMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
>
> The following regex will detect a good amount of Emojis:
>
> |/[\u{1f300}-\u{1f5ff}\u{1f900}-\u{1f9ff}\u{1f600}-\u{1f64f}\u{1f680}-\u{1f6ff}\u{2600}-\u{26ff}\u{2700}-\u{27bf}\u{1f1e6}-\u{1f1ff}\u{1f191}-\u{1f251}\u{1f004}\u{1f0cf}\u{1f170}-\u{1f171}\u{1f17e}-\u{1f17f}\u{1f18e}\u{3030}\u{2b50}\u{2b55}\u{2934}-\u{2935}\u{2b05}-\u{2b07}\u{2b1b}-\u{2b1c}\u{3297}\u{3299}\u{303d}\u{00a9}\u{00ae}\u{2122}\u{23f3}\u{24c2}\u{23e9}-\u{23ef}\u{25b6}\u{23f8}-\u{23fa}]/ug
>
> |
That doesn't work in SA for the same reason that \p{Emoticons}
doesn't work.
Re: Detect Emoticons in Subject: CHAOS
Clive Jacques wrote:
Hi,
I've been using SA a long time. Lately, I'm getting more and more
spam with emoticons in the subject line. I'd say about 90% of my
emails with emoticons in the subject are spam. I'd like to create a
local rule which scores email with emoticons in the subject. I saw a
previous discussion on this in the archive, but it was focused on
whether such emails were /always /spam. I think an emoticon rule, in
combination with other rules, will help my installation. I've tried
to match as follows, but it won't lint. I'm not really a perl
programmer. I've written several other more conventional local rules,
but here I'm a bit out of my depth. I'd appreciate some guidance.
# Local Rule for Emoticons in subject
subject EMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
score EMOTICON_IN_SUBJECT 3.0
describe EMOTICON_IN_SUBJECT Subject Line Has Emoticons
-CJ
The following regex will detect a good amount of Emojis:
|/[\u{1f300}-\u{1f5ff}\u{1f900}-\u{1f9ff}\u{1f600}-\u{1f64f}\u{1f680}-\u{1f6ff}\u{2600}-\u{26ff}\u{2700}-\u{27bf}\u{1f1e6}-\u{1f1ff}\u{1f191}-\u{1f251}\u{1f004}\u{1f0cf}\u{1f170}-\u{1f171}\u{1f17e}-\u{1f17f}\u{1f18e}\u{3030}\u{2b50}\u{2b55}\u{2934}-\u{2935}\u{2b05}-\u{2b07}\u{2b1b}-\u{2b1c}\u{3297}\u{3299}\u{303d}\u{00a9}\u{00ae}\u{2122}\u{23f3}\u{24c2}\u{23e9}-\u{23ef}\u{25b6}\u{23f8}-\u{23fa}]/ug
|
Ref:
https://stackoverflow.com/questions/43242440/javascript-unicode-emoji-regular-expressions/45138005#45138005
But it is not the greatest thing if you want to get a count out of that.
However, I may have a solution for you with the CHAOS plugin:
https://github.com/telecom2k3/CHAOS
You can get (but shouldn't) Emojis even in From names, like this actual one:
DHL☺com
CHAOS will also help you with Unicode Character spoofs, via its
UniBabble rulesets:
ᴀмαzσи ᴘ픯픦픪ё
혼픪픞혻홤혯 혾혶혴황홤혮혦혳 홎픢혳홫혪혤픢
Amαzoɴ Priⅿë
퐀퐦퐚퐳퐨퐧 퐍퐨퐭퐢퐜퐞
...
...
CHAOS will run on PERL 5.18 and later.
-- Jared Hall
Re: Detect Emoticons in Subject
That's fine - I'm not saying all email containing emojis in the subject (or elsewhere) *is *spam - just that it's uncommon and right now, about 90% of the time it is *for me*. I just want to score it as part of the greater constellation of factors (just like DKIM, SPF etc.). On Thu, May 20, 2021 at 2:48 PM Bill Cole < sausers-20150...@billmail.scconsult.com> wrote: > > People send wanted mail with all sorts of weirdness. > >
Re: Detect Emoticons in Subject
On 2021-05-20 at 13:44:43 UTC-0400 (Thu, 20 May 2021 18:44:43 +0100)
RW
is rumored to have said:
On Thu, 20 May 2021 18:30:03 +0100
RW wrote:
Try this:
header EMOTICON_IN_SUBJECT Subject =~
/\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/
Actually that's only the original block, but it probably works most of
the time
Not so sure about that...
I regularly get mail from Patreon with emoji in the encoded header which
don't match that pattern:
# grep '^Subject: ' /tmp/ham |cut -d? -f4 |decode-base64 |hexdump -C
f0 9f 8e 89 20 50 61 74 72 69 63 6b 20 57 61 72 |
Patrick War|
0010 64 6c 65 20 6a 75 73 74 20 73 68 61 72 65 64 20 |dle just
shared |
0020 22 f0 9f 93 9d 20 4e |" N|
0027
People send wanted mail with all sorts of weirdness.
Looking at the full set
(https://www.unicode.org/emoji/charts/full-emoji-list.html) I can
understand why \p{Emoticons} would be so much better than trying to
define them all in a regex of hex bytes in UTF-8 form.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 19:26:30 +0100 RW wrote: > On Thu, 20 May 2021 18:44:43 +0100 > RW wrote: > > > On Thu, 20 May 2021 18:30:03 +0100 > > RW wrote: > > > > > > > Try this: > > > > > > > > > header EMOTICON_IN_SUBJECT Subject =~ > > > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/ > > > > > > > Actually that's only the original block, but it probably works most > > of the time > > This extends it to Supplemental Symbols and Pictographs and > adds the three original faces from Miscellaneous Symbols > > > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xFF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/ > > it also fixes a minor problem with a continuation bytes in the > original. > I still didn't get continuity bytes right, I forgot that bit 6 is always 0 - it's a long time since I've done this. /\xF0\x9F(?:\x98[\x80-\xBF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xBF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 18:44:43 +0100 RW wrote: > On Thu, 20 May 2021 18:30:03 +0100 > RW wrote: > > > > Try this: > > > > > > header EMOTICON_IN_SUBJECT Subject =~ > > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/ > > > > Actually that's only the original block, but it probably works most of > the time This extends it to Supplemental Symbols and Pictographs and adds the three original faces from Miscellaneous Symbols /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x80-\x8F])|xF0\x9F(?:[\xA4-\xA6][\x80-\xFF]|\xA7[\x80-\xBF])|\xE2\x98[\xB9-\xBB]/ it also fixes a minor problem with a continuation bytes in the original.
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 18:30:03 +0100 RW wrote: > Try this: > > > header EMOTICON_IN_SUBJECT Subject =~ > /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/ > Actually that's only the original block, but it probably works most of the time
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 18:34:54 +0200 Bert Van de Poel wrote: > We've started getting lots of spam with emoji in the subject too the > past few weeks, so I've looked into this as well. As mentioned by RW, > you would need to create some kind of UTF8 regex header Subject rule. > As I'm not too excited about writing such a regex, it's way at the > bottom of my todo list to contemplate whether an SA plugin could be > written for that and to then reach out to the SA developers to see > whether that would be something upstream would accept. But honestly, > I won't be able to any time soon (I don't have the time). Still, > thought I'd mention it, since it might be relevant to your question. > If you do end up figuring out a regex that works out and isn't an > extreme length, I think plenty of people on this list would love to > know! Try this: header EMOTICON_IN_SUBJECT Subject =~ /\xF0\x9F(?:\x98[\x80-\xFF]|\x99[\x00-x8F])/
Re: Detect Emoticons in Subject
On Thu, 2021-05-20 at 18:34 +0200, Bert Van de Poel wrote: > We've started getting lots of spam with emoji in the subject too the > past few weeks, so I've looked into this as well. As mentioned by RW, > you would need to create some kind of UTF8 regex header Subject rule. As > I'm not too excited about writing such a regex, it's way at the bottom > of my todo list > Should be easy enough - IsASCII is just a name for [\x00-\x7f] and IsXDigit is [0-9a-fA-F], so the same logic can be applied to define a regex that triggers on any character within the three Unicode emoji ranges. See Wikipedia doe more detail: https://en.wikipedia.org/wiki/Emoticon#Unicode I haven't yet seen any emojis in Subject lines, regardless of whether the message was spam or not, or I'd probably have already written such a rule and given it a minimal score so it can be used in a more spam- specific meta rule. Martin
Re: Detect Emoticons in Subject
We've started getting lots of spam with emoji in the subject too the
past few weeks, so I've looked into this as well. As mentioned by RW,
you would need to create some kind of UTF8 regex header Subject rule. As
I'm not too excited about writing such a regex, it's way at the bottom
of my todo list to contemplate whether an SA plugin could be written for
that and to then reach out to the SA developers to see whether that
would be something upstream would accept. But honestly, I won't be able
to any time soon (I don't have the time). Still, thought I'd mention it,
since it might be relevant to your question. If you do end up figuring
out a regex that works out and isn't an extreme length, I think plenty
of people on this list would love to know!
Bert
On 20/05/2021 18:19, RW wrote:
On Thu, 20 May 2021 11:42:59 -0400
Clive Jacques wrote:
Hi,
I've been using SA a long time. Lately, I'm getting more and more
spam with emoticons in the subject line. I'd say about 90% of my
emails with emoticons in the subject are spam. I'd like to create a
local rule which scores email with emoticons in the subject.
# Local Rule for Emoticons in subject
subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
The rule should start with "header", that's what's causing the lint
failure.
However, AFAIK, the rule still won't work because \p{Emoticons}
isn't supported in spamassassin, which works on byte sequences. You
need to rewrite it to match UTF-8 bytes.
Re: Detect Emoticons in Subject
On Thu, 20 May 2021 11:42:59 -0400
Clive Jacques wrote:
> Hi,
>
> I've been using SA a long time. Lately, I'm getting more and more
> spam with emoticons in the subject line. I'd say about 90% of my
> emails with emoticons in the subject are spam. I'd like to create a
> local rule which scores email with emoticons in the subject.
> # Local Rule for Emoticons in subject
> subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
The rule should start with "header", that's what's causing the lint
failure.
However, AFAIK, the rule still won't work because \p{Emoticons}
isn't supported in spamassassin, which works on byte sequences. You
need to rewrite it to match UTF-8 bytes.
Detect Emoticons in Subject
Hi,
I've been using SA a long time. Lately, I'm getting more and more spam
with emoticons in the subject line. I'd say about 90% of my emails with
emoticons in the subject are spam. I'd like to create a local rule which
scores email with emoticons in the subject. I saw a previous discussion on
this in the archive, but it was focused on whether such emails were *always
*spam. I think an emoticon rule, in combination with other rules, will
help my installation. I've tried to match as follows, but it won't lint.
I'm not really a perl programmer. I've written several other more
conventional local rules, but here I'm a bit out of my depth. I'd
appreciate some guidance.
# Local Rule for Emoticons in subject
subjectEMOTICON_IN_SUBJECT Subject =~ /\p{Emoticons}/
score EMOTICON_IN_SUBJECT 3.0
describeEMOTICON_IN_SUBJECT Subject Line Has Emoticons
-CJ
Re: Scoring for "look alike" characters in subject?
Hi Steve, There are many rules that look at this. The FUZZY Logic rules might help and in the KAM ruleset, you'll see replace_tag lines and how they are used in various places to shutdown spammers used to obfuscate words by using other character sets and symbols. You can find the KAM.cf ruleset on mcgrail.com under downloads and there is an SA Channel for it as well. regards, KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Mon, Mar 15, 2021 at 6:59 AM Steve Dondley wrote: > I'm noticing a fair amount of spam getting through using letters in the > subject line that are outside the standard set of ASCII characters in an > effort to bypass spam filters. For example, instead of a capital "R", > there will be a letter that closely approximates a capital "R" but when > you look closely at it, you'll see the bottom of the rounded part of the > "R" never connects to the line running along the left side of the > letter. > > I don't want to use a rule that is too-restrictive (like maybe banning > all non-standard ascii characters) but I also want to increase the > likelihood of email using these tactics getting flagged as spam. > > I'm new to spamasssassin so I'm not sure if a rule like this already > exists or how I might go about finding this rule or what I should weight > it. I'm wondering if others on the list have rules to address this same > issue and can share their rule. Thanks. >
Scoring for "look alike" characters in subject?
I'm noticing a fair amount of spam getting through using letters in the subject line that are outside the standard set of ASCII characters in an effort to bypass spam filters. For example, instead of a capital "R", there will be a letter that closely approximates a capital "R" but when you look closely at it, you'll see the bottom of the rounded part of the "R" never connects to the line running along the left side of the letter. I don't want to use a rule that is too-restrictive (like maybe banning all non-standard ascii characters) but I also want to increase the likelihood of email using these tactics getting flagged as spam. I'm new to spamasssassin so I'm not sure if a rule like this already exists or how I might go about finding this rule or what I should weight it. I'm wondering if others on the list have rules to address this same issue and can share their rule. Thanks.
Re: BCC Rule and Subject change for specific rule
On Wed, 6 Jan 2021, Giovanni Bechis wrote: On 1/6/21 2:40 PM, RW wrote: On Tue, 5 Jan 2021 10:14:45 -0800 (PST) John Hardin wrote: On Tue, 5 Jan 2021, Dave Funk wrote: On Tue, 5 Jan 2021, John Hardin wrote: subjprefix FROM_ME [From Me] Does this work if you're using a milter for your glue? Is there some special status/command that spamd returns to the milter for this kind of modification? If so the milters may need to be recoded to implement it. No, it's rewriting the message headers before passing the message back to the MTA. It's already adding a [SPAM] tag to the subject by default (if enabled). This just allows customization of that behavior. Assuming that the scan itself adds the headers. I was under the impression that amavisd adds its own headers. There's also this rather vague remark in the documentation: "To be able to use this feature a "add_header all Subjprefix _SUBJPREFIX_" configuration line could be needed on some setups." This is needed to let amavisd (from next released version afaik) or Mimedefang (with a custom mimedefang-filter snippet) parse the headers and correctly rewrite the subject. The docs should probably be amended to reflect that, and add a usage example. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Je ne suis pas Charlie. Je suis armé. --- Tomorrow: the 6th anniversary of the Charlie Hebdo massacre
Re: BCC Rule and Subject change for specific rule
On 1/6/21 2:40 PM, RW wrote: > On Tue, 5 Jan 2021 10:14:45 -0800 (PST) > John Hardin wrote: > >> On Tue, 5 Jan 2021, Dave Funk wrote: >> >>> On Tue, 5 Jan 2021, John Hardin wrote: > >>>>> subjprefix FROM_ME [From Me] >>>> > >>> >>> Does this work if you're using a milter for your glue? >>> >>> Is there some special status/command that spamd returns to the >>> milter for this kind of modification? If so the milters may need to >>> be recoded to implement it. >> >> No, it's rewriting the message headers before passing the message >> back to the MTA. It's already adding a [SPAM] tag to the subject by >> default (if enabled). This just allows customization of that behavior. > > Assuming that the scan itself adds the headers. I was under the > impression that amavisd adds its own headers. > > > There's also this rather vague remark in the documentation: > > "To be able to use this feature a "add_header all Subjprefix > _SUBJPREFIX_" configuration line could be needed on some setups." > This is needed to let amavisd (from next released version afaik) or Mimedefang (with a custom mimedefang-filter snippet) parse the headers and correctly rewrite the subject. Giovanni
Re: BCC Rule and Subject change for specific rule
On Tue, 5 Jan 2021 10:14:45 -0800 (PST) John Hardin wrote: > On Tue, 5 Jan 2021, Dave Funk wrote: > > > On Tue, 5 Jan 2021, John Hardin wrote: > >>> subjprefix FROM_ME [From Me] > >> > > > > Does this work if you're using a milter for your glue? > > > > Is there some special status/command that spamd returns to the > > milter for this kind of modification? If so the milters may need to > > be recoded to implement it. > > No, it's rewriting the message headers before passing the message > back to the MTA. It's already adding a [SPAM] tag to the subject by > default (if enabled). This just allows customization of that behavior. Assuming that the scan itself adds the headers. I was under the impression that amavisd adds its own headers. There's also this rather vague remark in the documentation: "To be able to use this feature a "add_header all Subjprefix _SUBJPREFIX_" configuration line could be needed on some setups."
Re: BCC Rule and Subject change for specific rule
On Tue, 5 Jan 2021, Dave Funk wrote: On Tue, 5 Jan 2021, John Hardin wrote: On Tue, 5 Jan 2021, Giovanni Bechis wrote: On Mon, Jan 04, 2021 at 05:23:30PM -0800, John Hardin wrote: I'm pretty sure SA only allows setting the subject tag by language, not based on rule hits. Starting from 3.4.3 you can add a prefix to the email subject like that: header FROM_ME From:name =~ /Me/ subjprefix FROM_ME [From Me] Cool, I missed that at the time. Thanks! The documentation does mention it exists but does not give an example of using it... Does this work if you're using a milter for your glue? Is there some special status/command that spamd returns to the milter for this kind of modification? If so the milters may need to be recoded to implement it. No, it's rewriting the message headers before passing the message back to the MTA. It's already adding a [SPAM] tag to the subject by default (if enabled). This just allows customization of that behavior. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- 220 days since the first private commercial manned orbital mission (SpaceX)
Re: BCC Rule and Subject change for specific rule
On Tue, 5 Jan 2021, John Hardin wrote:
On Tue, 5 Jan 2021, Giovanni Bechis wrote:
On Mon, Jan 04, 2021 at 05:23:30PM -0800, John Hardin wrote:
I'm pretty sure SA only allows setting the subject tag by language, not
based on rule hits.
Starting from 3.4.3 you can add a prefix to the email subject like that:
header FROM_ME From:name =~ /Me/
subjprefix FROM_ME [From Me]
Cool, I missed that at the time. Thanks!
The documentation does mention it exists but does not give an example of
using it...
Does this work if you're using a milter for your glue?
Is there some special status/command that spamd returns to the milter for this
kind of modification? If so the milters may need to be recoded to implement it.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-05491256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: BCC Rule and Subject change for specific rule
On Tue, 5 Jan 2021, Giovanni Bechis wrote: On Mon, Jan 04, 2021 at 05:23:30PM -0800, John Hardin wrote: I'm pretty sure SA only allows setting the subject tag by language, not based on rule hits. Starting from 3.4.3 you can add a prefix to the email subject like that: header FROM_ME From:name =~ /Me/ subjprefix FROM_ME [From Me] Cool, I missed that at the time. Thanks! The documentation does mention it exists but does not give an example of using it... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Your mouse has moved. Your Windows Operating System must be relicensed due to this hardware change. Please contact Microsoft to obtain a new activation key. If this hardware change results in added functionality you may be subject to additional license fees. Your system will now shut down. Thank you for choosing Microsoft. --- 220 days since the first private commercial manned orbital mission (SpaceX)
Re: BCC Rule and Subject change for specific rule
On Mon, Jan 04, 2021 at 05:23:30PM -0800, John Hardin wrote: > On Mon, 4 Jan 2021, Joey J wrote: > > > If I'm understanding things correctly, there is a way for me to BCC spam > > messages which lets say score 10 and send a BCC to an email address, but > > I'm trying to do it within only 1 rule, as well as modify the subject. > > > > What I don't want is a BCC sent for every messages which is scored a 10, > > but only the specific rule. > > > > Is there a way for me to accomplish this set of actions? > > You can't BCC the message within SpamAssassin, as SA only scores messages. > The MTA or glue layer (what ties SA into your MTA) is what determines > *delivery* of the message based on SA's score. > > Potentially, your MTA or glue layer could be configured to look for a > specific scored rule name appearing in the header that lists rule hits and > if found deliver the message to another destination. > > But specifically how to do that depends on your MTA and/or your glue. What > are you using? > > I'm pretty sure SA only allows setting the subject tag by language, not > based on rule hits. You may beable to modify the subject in the MTA/glue > at the same point you do the extra delivery. > Starting from 3.4.3 you can add a prefix to the email subject like that: header FROM_ME From:name =~ /Me/ subjprefix FROM_ME [From Me] Giovanni signature.asc Description: PGP signature
Re: BCC Rule and Subject change for specific rule
On 4 Jan 2021, at 20:49, Joey J wrote: Thanks for the follow up. I understand what you are saying. This is SA within ProxMox Mail gateway, I added my custom rule via SA which is working, just this additional function. So this is really a question for Proxmox experts. There seems to be a user forum at https://forum.proxmox.com/#proxmox-mail-gateway.4 where you may find help specific to Proxmox. In general, the way to handle messages differently based on specific SA test hits is to have whatever is calling SA look for the special rule name(s) in the list of hits returned by SA and change the handling based on what is found. Depending on how exactly the "glue" (e.g: a milter, a proxy filter, or a delivery filter) operates, that can mean examining a parsed rule list in the glue layer itself or examining a header added by the glue layer in the MTA or even downstream from the MTA in the delivery path. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: BCC Rule and Subject change for specific rule
Thanks for the follow up. I understand what you are saying. This is SA within ProxMox Mail gateway, I added my custom rule via SA which is working, just this additional function. On Mon, Jan 4, 2021 at 8:23 PM John Hardin wrote: > On Mon, 4 Jan 2021, Joey J wrote: > > > If I'm understanding things correctly, there is a way for me to BCC spam > > messages which lets say score 10 and send a BCC to an email address, but > > I'm trying to do it within only 1 rule, as well as modify the subject. > > > > What I don't want is a BCC sent for every messages which is scored a 10, > > but only the specific rule. > > > > Is there a way for me to accomplish this set of actions? > > You can't BCC the message within SpamAssassin, as SA only scores messages. > The MTA or glue layer (what ties SA into your MTA) is what determines > *delivery* of the message based on SA's score. > > Potentially, your MTA or glue layer could be configured to look for a > specific scored rule name appearing in the header that lists rule hits and > if found deliver the message to another destination. > > But specifically how to do that depends on your MTA and/or your glue. What > are you using? > > I'm pretty sure SA only allows setting the subject tag by language, not > based on rule hits. You may beable to modify the subject in the MTA/glue > at the same point you do the extra delivery. > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > jhar...@impsec.org pgpk -a jhar...@impsec.org > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- >News flash: Lowest Common Denominator down 50 points > --- > 219 days since the first private commercial manned orbital mission > (SpaceX) > -- Thanks! Joey
Re: BCC Rule and Subject change for specific rule
On Mon, 4 Jan 2021, Joey J wrote: If I'm understanding things correctly, there is a way for me to BCC spam messages which lets say score 10 and send a BCC to an email address, but I'm trying to do it within only 1 rule, as well as modify the subject. What I don't want is a BCC sent for every messages which is scored a 10, but only the specific rule. Is there a way for me to accomplish this set of actions? You can't BCC the message within SpamAssassin, as SA only scores messages. The MTA or glue layer (what ties SA into your MTA) is what determines *delivery* of the message based on SA's score. Potentially, your MTA or glue layer could be configured to look for a specific scored rule name appearing in the header that lists rule hits and if found deliver the message to another destination. But specifically how to do that depends on your MTA and/or your glue. What are you using? I'm pretty sure SA only allows setting the subject tag by language, not based on rule hits. You may beable to modify the subject in the MTA/glue at the same point you do the extra delivery. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.org pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- News flash: Lowest Common Denominator down 50 points --- 219 days since the first private commercial manned orbital mission (SpaceX)
BCC Rule and Subject change for specific rule
Hello All, If I'm understanding things correctly, there is a way for me to BCC spam messages which lets say score 10 and send a BCC to an email address, but I'm trying to do it within only 1 rule, as well as modify the subject. What I don't want is a BCC sent for every messages which is scored a 10, but only the specific rule. Is there a way for me to accomplish this set of actions? Thanks! -- Thanks! Joey
[no subject]
How can I mark emails as being spam originating from an ip range owned by xserver.ua? % Abuse contact for '176.103.48.0 - 176.103.63.255' is 'ab...@xserver.ua' inetnum:176.103.48.0 - 176.103.63.255 netname:XServer-IP-Network-6 country:UA org:ORG-IV2-RIPE admin-c:IV25-RIPE tech-c: IV25-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: MNT-IV25 mnt-routes: MNT-IV25 mnt-routes: ITL-MNT mnt-domains:MNT-IV25 created:2011-12-09T13:10:04Z last-modified: 2017-05-24T13:24:15Z source: RIPE # Filtered sponsoring-org: ORG-ML410-RIPE organisation: ORG-IV2-RIPE org-name: PE Ivanov Vitaliy Sergeevich org-type: OTHER address:42-A Tobolskaya street, office 230, Kharkov, Ukraine phone: +380 57 728 12 67 abuse-c:AR19840-RIPE mnt-ref:MNT-IV25 mnt-by: MNT-IV25 created:2009-06-16T15:24:59Z last-modified: 2017-05-12T08:36:23Z source: RIPE # Filtered person: Ivanov Vitaliy address:42-A Tobolskaya street, office 230, Kharkov, Ukraine phone: +380 57 728 12 67 nic-hdl:IV25-RIPE mnt-by: MNT-IV25 created:2009-06-16T15:19:31Z last-modified: 2017-05-12T08:37:26Z source: RIPE # Filtered % Information related to '176.103.48.0/20AS48031' route: 176.103.48.0/20 descr: XSERVER origin: AS48031 mnt-by: MNT-IV25 created:2012-03-02T11:27:45Z last-modified: 2012-03-02T11:27:45Z source: RIPE
Solved: Subject not always included as first line of body
SOLVED:
I think it may be a Perl 5.24.1 bug... SA $msg cache gets empty randomly!
i have written a small patch, if someone suffers the same problem, contact me..
not the best patch possible, but it works with minimum impact.
-
Pedreter.
On Friday, October 4, 2019, 6:49:41 PM GMT+2, Pedro David Marco
wrote:
Hi!
In SA 3.4.2 I have noticed a slight score difference between consecutive SA
executions.
Digging out, i have discovered that in plugin methods that use $body from the
third argument, like in this example:
sub pdf_is_empty_body { my ($self, $pms, $body, $min) = @_;
the subject is not always included as first line of body (as expected), but
only in 50% of calls (aprox.)
In SA 3.4.1 it works ok.
any idea of why?
(I have asked as well to dev list)
Thanks.-Pedreter
Subject not always included as first line of body
Hi!
In SA 3.4.2 I have noticed a slight score difference between consecutive SA
executions.
Digging out, i have discovered that in plugin methods that use $body from the
third argument, like in this example:
sub pdf_is_empty_body { my ($self, $pms, $body, $min) = @_;
the subject is not always included as first line of body (as expected), but
only in 50% of calls (aprox.)
In SA 3.4.1 it works ok.
any idea of why?
(I have asked as well to dev list)
Thanks.-Pedreter
Subject score differs from actual score
Hi, I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" There is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. Here is another one: https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/TI3K42RGVJ3ZB6O4NUPNCUWHGVHNDY53/ 8.4 in the subject but "X-Spam-Status: No, score=4.9" Here is my /etc/spamassassin/local.cf (~/.spamassassin config is not used): rewrite_header Subject * SPAM _SCORE_ * report_safe 0 required_score 5.0 use_bayes 1 use_bayes_rules 1 bayes_auto_learn1 skip_rbl_checks 0 use_razor2 0 use_dcc 0 use_pyzor 0 -- David Galloway Systems Administrator, RDU Ceph Engineering IRC: dgalloway
Re: Score in subject differs from score in headers
On 9/6/19 4:16 PM, Matus UHLAR - fantomas wrote: >>>> On 9/6/2019 11:45 AM, David Galloway wrote: >>>>> I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and >>>>> Mailman3. >>>>> >>>>> Occasionally, SpamAssassin will rewrite a message's subject with a >>>>> score >>>>> higher than what's in X-Spam-Status. This is not a rounding issue. >>>>> >>>>> For example, I'm looking at an e-mail now with "* SPAM 5.4 >>>>> *" in >>>>> the subject but "X-Spam-Status: No, score=3.2 required=5.0" >>>>> >>>>> AFAIK, there is no instance of SpamAssassin between the mail server >>>>> and >>>>> me that >>>>> could have added the score to the subject. > > On 06.09.19 16:11, David Galloway wrote: >> I'm not crazy! > >> https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/GN3DLKWDIW2NUDO4T4MZG6E5FQEIB7NN/ >> >> >> 7.3 in the subject (that my SpamAssassin instance definitely set) and: >> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on lists.ceph.io >> X-Spam-Level: * >> X-Spam-Status: No, score=1.8 required=5.0 >> tests=FREEMAIL_REPLYTO_END_DIGIT, >> MAILING_LIST_MULTI,RCVD_IN_RP_RNBL,RDNS_NONE,SPF_HELO_NONE, >> SUBJ_OBFU_PUNCT_FEW,URIBL_BLOCKED autolearn=no autolearn_force=no >> version=3.4.2 > > are you sure you don't process mail two times, when delivering to list and > when delivering to end-users (you)? > Oof, that is exactly what was happening. Which leads me to figuring out why my mailman header filter regex isn't working. Anyway, thanks for the help!
Re: Score in subject differs from score in headers
On 9/6/2019 11:45 AM, David Galloway wrote: I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" AFAIK, there is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. On 06.09.19 16:11, David Galloway wrote: I'm not crazy! https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/GN3DLKWDIW2NUDO4T4MZG6E5FQEIB7NN/ 7.3 in the subject (that my SpamAssassin instance definitely set) and: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on lists.ceph.io X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=FREEMAIL_REPLYTO_END_DIGIT, MAILING_LIST_MULTI,RCVD_IN_RP_RNBL,RDNS_NONE,SPF_HELO_NONE, SUBJ_OBFU_PUNCT_FEW,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 are you sure you don't process mail two times, when delivering to list and when delivering to end-users (you)? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges.
Re: Score in subject differs from score in headers
On 9/6/19 12:06 PM, David Galloway wrote: > > On 9/6/19 12:01 PM, Bowie Bailey wrote: >> On 9/6/2019 11:45 AM, David Galloway wrote: >>> Hi, >>> >>> I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. >>> >>> Occasionally, SpamAssassin will rewrite a message's subject with a score >>> higher than what's in X-Spam-Status. This is not a rounding issue. >>> >>> For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in >>> the subject but "X-Spam-Status: No, score=3.2 required=5.0" >>> >>> AFAIK, there is no instance of SpamAssassin between the mail server and >>> me that >>> could have added the score to the subject. >> >> The instance of SpamAssassin that changed the subject would have been before >> it got >> to your server. Since your server does not mark the email as spam, it >> doesn't change >> the subject, and so the previous markup is left there. If your server had >> marked the >> email as spam, then it would have either changed the number to be correct, >> or added a >> second spam tag to the subject (depending on how smart SA's subject >> rewriting routine >> is). >> > > I didn't start seeing the subjects being changed until after I enabled > SpamAssassin on my mail server though. I don't /think/ I'm crazy but as > a litmus test, I just added my server's hostname to the rewrite_header > Subject parameter and will wait for spam to come in. > I'm not crazy! https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/GN3DLKWDIW2NUDO4T4MZG6E5FQEIB7NN/ 7.3 in the subject (that my SpamAssassin instance definitely set) and: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on lists.ceph.io X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=FREEMAIL_REPLYTO_END_DIGIT, MAILING_LIST_MULTI,RCVD_IN_RP_RNBL,RDNS_NONE,SPF_HELO_NONE, SUBJ_OBFU_PUNCT_FEW,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2
Re: Score in subject differs from score in headers
On 6 Sep 2019, at 10:35, Riccardo Alfieri wrote: > On 06/09/19 17:45, David Galloway wrote: > >> For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in >> the subject but "X-Spam-Status: No, score=3.2 required=5.0" > > since when does SpamAssassin also writes the scores in the subject? It's a > cool feature that I probably missed completely Since forever? Nearly forever? I used to use (Spam? _SCORE_) when I tagged subjects. I no longer do that. I do not recommend that anyone do that, it causes more trouble than it’s worth. (I am pretty sure that is the syntax, it’s been a number of years). As for your issue, I suspect you are double processing mail (been there, done that, have the t-shirt) and that one process is applying the higher score to the subject. -- You've never heard of the Millennium Falcon?
Re: Score in subject differs from score in headers
On 06/09/19 19:36, Bill Cole wrote: Since pretty much forever, IF it is told to do so... See the documentation of 'rewrite_header' in 'perldoc Mail::SpamAssassin::Conf' Thanks for pointing that out, I never realized template tags could be used on the subject rewriting too. I guess my fault was/is using SA with amavisd, that redefines subject rewriting in it's own way (maybe it could add scores in subject too out of the box? Don't know, better RTFM ;) ) -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaustech.com/
Re: Score in subject differs from score in headers
On 6 Sep 2019, at 12:35, Riccardo Alfieri wrote: On 06/09/19 17:45, David Galloway wrote: For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" Hi, since when does SpamAssassin also writes the scores in the subject? Since pretty much forever, IF it is told to do so... See the documentation of 'rewrite_header' in 'perldoc Mail::SpamAssassin::Conf' The entire 'rewrite_header' feature is generally a bad idea but people like it so it has survived. It's a cool feature that I probably missed completely :) It's really not a cool feature. Breaking signatures is obnoxious. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Score in subject differs from score in headers
On 06/09/19 17:45, David Galloway wrote: For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" Hi, since when does SpamAssassin also writes the scores in the subject? It's a cool feature that I probably missed completely :) -- Best regards, Riccardo Alfieri Spamhaus Technology https://www.spamhaustech.com/
Re: Score in subject differs from score in headers
On 9/6/19 12:01 PM, Bowie Bailey wrote: > On 9/6/2019 11:45 AM, David Galloway wrote: >> Hi, >> >> I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. >> >> Occasionally, SpamAssassin will rewrite a message's subject with a score >> higher than what's in X-Spam-Status. This is not a rounding issue. >> >> For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in >> the subject but "X-Spam-Status: No, score=3.2 required=5.0" >> >> AFAIK, there is no instance of SpamAssassin between the mail server and >> me that >> could have added the score to the subject. > > The instance of SpamAssassin that changed the subject would have been before > it got > to your server. Since your server does not mark the email as spam, it > doesn't change > the subject, and so the previous markup is left there. If your server had > marked the > email as spam, then it would have either changed the number to be correct, or > added a > second spam tag to the subject (depending on how smart SA's subject rewriting > routine > is). > I didn't start seeing the subjects being changed until after I enabled SpamAssassin on my mail server though. I don't /think/ I'm crazy but as a litmus test, I just added my server's hostname to the rewrite_header Subject parameter and will wait for spam to come in.
Re: Score in subject differs from score in headers
On 9/6/2019 11:45 AM, David Galloway wrote: > Hi, > > I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. > > Occasionally, SpamAssassin will rewrite a message's subject with a score > higher than what's in X-Spam-Status. This is not a rounding issue. > > For example, I'm looking at an e-mail now with "***** SPAM 5.4 *" in > the subject but "X-Spam-Status: No, score=3.2 required=5.0" > > AFAIK, there is no instance of SpamAssassin between the mail server and > me that > could have added the score to the subject. The instance of SpamAssassin that changed the subject would have been before it got to your server. Since your server does not mark the email as spam, it doesn't change the subject, and so the previous markup is left there. If your server had marked the email as spam, then it would have either changed the number to be correct, or added a second spam tag to the subject (depending on how smart SA's subject rewriting routine is). -- Bowie
Re: Score in subject differs from score in headers
On 06.09.19 11:45, David Galloway wrote: I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" it's always possible that subject was there before your SA kicked in. btw. I recommend not changing subject in SA. AFAIK, there is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901
Score in subject differs from score in headers
Hi, I'm running SpamAssassin 3.4.2 on Ubuntu 16.04 with Postfix and Mailman3. Occasionally, SpamAssassin will rewrite a message's subject with a score higher than what's in X-Spam-Status. This is not a rounding issue. For example, I'm looking at an e-mail now with "* SPAM 5.4 *" in the subject but "X-Spam-Status: No, score=3.2 required=5.0" AFAIK, there is no instance of SpamAssassin between the mail server and me that could have added the score to the subject. Here is another one: https://lists.ceph.io/hyperkitty/list/d...@ceph.io/thread/TI3K42RGVJ3ZB6O4NUPNCUWHGVHNDY53/ 8.4 in the subject but "X-Spam-Status: No, score=4.9" Here is my /etc/spamassassin/local.cf (~/.spamassassin config is not used): rewrite_header Subject * SPAM _SCORE_ * report_safe 0 required_score 5.0 use_bayes 1 use_bayes_rules 1 bayes_auto_learn1 skip_rbl_checks 0 use_razor2 0 use_dcc 0 use_pyzor 0 -- David Galloway Systems Administrator, RDU Ceph Engineering IRC: dgalloway
Re: MISSING_SUBJECT rule on email with subject
Hi Charles, Yes, it was an incorrectly escaped forward slash in a subject rule. On 2019/06/24 16:12, Charles Amstutz wrote: Hi Charles, My apologies, I forgot to provide feedback to the mailing list. Bad regex was the cause of this problem for us, too. As soon as the custom rule was fixed, the problem went away. If I can ask, was it an incorrectly escaped special character? I think it is the @ symbol breaking mine.
Re: MISSING_SUBJECT rule on email with subject
Hi Charles, My apologies, I forgot to provide feedback to the mailing list. Bad regex was the cause of this problem for us, too. As soon as the custom rule was fixed, the problem went away. Kind Regards, Stephan On 2019/06/24 15:58, Charles Amstutz wrote: But as has already been pointed out it has the combination of MISSING_FROM and HK_RANDOM_FROM, and the latter is based on a From:addr test. I saw this too, however, I thought I noticed a potentially bad regex (from another custom rule) breaking mine. I think this is the case as when I removed the rule, it stopped the missing_subject stopped hitting. However, I'm still testing.
RE: MISSING_SUBJECT rule on email with subject
> But as has already been pointed out it has the combination of > MISSING_FROM and HK_RANDOM_FROM, and the latter is based on a > From:addr test. I saw this too, however, I thought I noticed a potentially bad regex (from another custom rule) breaking mine. I think this is the case as when I removed the rule, it stopped the missing_subject stopped hitting. However, I'm still testing.
Re: MISSING_SUBJECT rule on email with subject
On Tue, 4 Jun 2019 18:10:51 +0300 Savvas Karagiannidis wrote: > Hi, > > my guess is that for some reason an empty line is inserted in the > email somewhere above the headers and before the message is processed > by spamassassin. This will cause all headers below this empty line to > be treated as the actual body of the message, so all missing header > tests will hit and will result in what you actually see. But as has already been pointed out it has the combination of MISSING_FROM and HK_RANDOM_FROM, and the latter is based on a From:addr test.
Re: MISSING_SUBJECT rule on email with subject
Hi, my guess is that for some reason an empty line is inserted in the email somewhere above the headers and before the message is processed by spamassassin. This will cause all headers below this empty line to be treated as the actual body of the message, so all missing header tests will hit and will result in what you actually see. This could be a bug in the software you use for email content filtering... Regards, Savvas Karagiannidis On 04/06/2019 17:29, Stephan Fourie wrote: Hi, My apologies, seems something went wrong with the formatting when it was pasted to the pastebin. Here's a new example with spacing intact: https://pastebin.com/raw/tQtSMQPs In this example some of the other headers were also not 'seen'. Thanks! Stephan On 2019/06/04 10:55, Matus UHLAR - fantomas wrote: On 3 Jun 2019, at 2:20, Stephan Fourie wrote: > We're currently seeing the rule MISSING_SUBJECT sporadically > hitting on emails that have a subject. This issue seems to have > started during last week, which is when clients started complaining > about false positive detections. Please see example headers at the > following link: > > https://pastebin.com/raw/GtnV67Hj On Mon, 03 Jun 2019 11:43:44 -0400 Bill Cole wrote: The headers are all missing the traditional space between the colon and the header content. On 03.06.19 19:11, RW wrote: And this include google headers, so presumably the spaces have been stripped locally. now one question is, if the spaces have been stripped prior to spam checking, another is, if SA does/should expect whitespaces after header fields. if the first answer is true, then SA can't do much about misformatted e-mail. But since FROM_AND_TO_IS_SAME_DOMAIN was hit, I don't think the spaces were stripped, so - we need to see the original message as it was scanned. Anything else, reformated by anyone (e.g. outlook or exchange use to reformat mail), can't help us much finding the issue.
Re: MISSING_SUBJECT rule on email with subject
On 04.06.19 16:29, Stephan Fourie wrote: My apologies, seems something went wrong with the formatting when it was pasted to the pastebin. Here's a new example with spacing intact: https://pastebin.com/raw/tQtSMQPs In this example some of the other headers were also not 'seen'. there's something strange: 1.0 HK_RANDOM_FROM From username looks random 0.5 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (x[at]gmail.com) 1.0 MISSING_FROM Missing From: header 1.8 MISSING_SUBJECTMissing Subject: header so the spam scanner both did and did not see the From: header. What do you use for mail scanning? On 2019/06/04 10:55, Matus UHLAR - fantomas wrote: On 3 Jun 2019, at 2:20, Stephan Fourie wrote: We're currently seeing the rule MISSING_SUBJECT sporadically hitting on emails that have a subject. This issue seems to have started during last week, which is when clients started complaining about false positive detections. Please see example headers at the following link: https://pastebin.com/raw/GtnV67Hj On Mon, 03 Jun 2019 11:43:44 -0400 Bill Cole wrote: The headers are all missing the traditional space between the colon and the header content. On 03.06.19 19:11, RW wrote: And this include google headers, so presumably the spaces have been stripped locally. now one question is, if the spaces have been stripped prior to spam checking, another is, if SA does/should expect whitespaces after header fields. if the first answer is true, then SA can't do much about misformatted e-mail. But since FROM_AND_TO_IS_SAME_DOMAIN was hit, I don't think the spaces were stripped, so - we need to see the original message as it was scanned. Anything else, reformated by anyone (e.g. outlook or exchange use to reformat mail), can't help us much finding the issue. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm
Re: MISSING_SUBJECT rule on email with subject
Hi, My apologies, seems something went wrong with the formatting when it was pasted to the pastebin. Here's a new example with spacing intact: https://pastebin.com/raw/tQtSMQPs In this example some of the other headers were also not 'seen'. Thanks! Stephan On 2019/06/04 10:55, Matus UHLAR - fantomas wrote: On 3 Jun 2019, at 2:20, Stephan Fourie wrote: > We're currently seeing the rule MISSING_SUBJECT sporadically > hitting on emails that have a subject. This issue seems to have > started during last week, which is when clients started complaining > about false positive detections. Please see example headers at the > following link: > > https://pastebin.com/raw/GtnV67Hj On Mon, 03 Jun 2019 11:43:44 -0400 Bill Cole wrote: The headers are all missing the traditional space between the colon and the header content. On 03.06.19 19:11, RW wrote: And this include google headers, so presumably the spaces have been stripped locally. now one question is, if the spaces have been stripped prior to spam checking, another is, if SA does/should expect whitespaces after header fields. if the first answer is true, then SA can't do much about misformatted e-mail. But since FROM_AND_TO_IS_SAME_DOMAIN was hit, I don't think the spaces were stripped, so - we need to see the original message as it was scanned. Anything else, reformated by anyone (e.g. outlook or exchange use to reformat mail), can't help us much finding the issue.
Re: MISSING_SUBJECT rule on email with subject
On 3 Jun 2019, at 2:20, Stephan Fourie wrote: > We're currently seeing the rule MISSING_SUBJECT sporadically > hitting on emails that have a subject. This issue seems to have > started during last week, which is when clients started complaining > about false positive detections. Please see example headers at the > following link: > > https://pastebin.com/raw/GtnV67Hj On Mon, 03 Jun 2019 11:43:44 -0400 Bill Cole wrote: The headers are all missing the traditional space between the colon and the header content. On 03.06.19 19:11, RW wrote: And this include google headers, so presumably the spaces have been stripped locally. now one question is, if the spaces have been stripped prior to spam checking, another is, if SA does/should expect whitespaces after header fields. if the first answer is true, then SA can't do much about misformatted e-mail. But since FROM_AND_TO_IS_SAME_DOMAIN was hit, I don't think the spaces were stripped, so - we need to see the original message as it was scanned. Anything else, reformated by anyone (e.g. outlook or exchange use to reformat mail), can't help us much finding the issue. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are...
Re: MISSING_SUBJECT rule on email with subject
On Mon, 03 Jun 2019 11:43:44 -0400 Bill Cole wrote: > On 3 Jun 2019, at 2:20, Stephan Fourie wrote: > > > Hi, > > > > We're currently seeing the rule MISSING_SUBJECT sporadically > > hitting on emails that have a subject. This issue seems to have > > started during last week, which is when clients started complaining > > about false positive detections. Please see example headers at the > > following link: > > > > https://pastebin.com/raw/GtnV67Hj > > The headers are all missing the traditional space between the colon > and the header content. And this include google headers, so presumably the spaces have been stripped locally.
Re: MISSING_SUBJECT rule on email with subject
On 3 Jun 2019, at 2:20, Stephan Fourie wrote: Hi, We're currently seeing the rule MISSING_SUBJECT sporadically hitting on emails that have a subject. This issue seems to have started during last week, which is when clients started complaining about false positive detections. Please see example headers at the following link: https://pastebin.com/raw/GtnV67Hj The headers are all missing the traditional space between the colon and the header content. This is formally allowable (see https://tools.ietf.org/html/rfc5322#appendix-A.5,) but it may be breaking the parsing of the message. More significantly, there are what appear to be continuation parts of folded headers which have no leading whitespace, which is NOT allowable and will definitely break parsing. Is this an artifact of how you copied the message or is it really that way? If the misformatting is being done by something before SpamAssassin sees it, SA will parse the headers incorrectly.
MISSING_SUBJECT rule on email with subject
Hi, We're currently seeing the rule MISSING_SUBJECT sporadically hitting on emails that have a subject. This issue seems to have started during last week, which is when clients started complaining about false positive detections. Please see example headers at the following link: https://pastebin.com/raw/GtnV67Hj Has anyone seen the same or similar issue recently? If not, can anyone offer some advice or guidance? Thanks! Stephan
Re: FROM_IN_TO_AND_SUBJ hits on emails with empty subject
On Wed, 30 Jan 2019, Olivier Coutu wrote:
meta FROM_IN_TO_AND_SUBJ (__TO_EQ_FROM && __SUBJ_HAS_FROM_1)
header __SUBJ_HAS_FROM_1 ALL =~
/\nFrom:\s+(?:[^\n<]{0,80}<)?([^\n\s>]+)>?\n(?:[^\n]{1,100}\n)*Subject:\s+[^\n]{0,100}\1[>,\s\n]/ism
If the from and the to are identical and the subject is empty, this rule
hits, e.g.
From: custo...@example.com
Subject:
To: "Scan PC"
Since there is no restriction for \n in the \s+ after the subject, the /to/
in the next line is matched. An easy fix would be to change \s+ by [ \t]+ or
something similar. The rule could also be cancelled by __SUBJECT_EMPTY
Thanks for the report, I will fix that tonight.
--
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
---
So Microsoft's invented the ASCII equivalent to ugly ink spots that
appear on your letter when your pen is malfunctioning.
-- Greg Andrews, about Microsoft's way to encode apostrophes
---
2 days until the 16th anniversary of the loss of STS-107 Columbia
FROM_IN_TO_AND_SUBJ hits on emails with empty subject
meta FROM_IN_TO_AND_SUBJ (__TO_EQ_FROM && __SUBJ_HAS_FROM_1)
header __SUBJ_HAS_FROM_1 ALL =~
/\nFrom:\s+(?:[^\n<]{0,80}<)?([^\n\s>]+)>?\n(?:[^\n]{1,100}\n)*Subject:\s+[^\n]{0,100}\1[>,\s\n]/ism
If the from and the to are identical and the subject is empty, this rule
hits, e.g.
From: custo...@example.com
Subject:
To: "Scan PC"
Since there is no restriction for \n in the \s+ after the subject, the
/to/ in the next line is matched. An easy fix would be to change \s+ by
[ \t]+ or something similar. The rule could also be cancelled by
__SUBJECT_EMPTY
[no subject]
test
Re: rewrite_header Subject and Bayes
On 30.05.18 15:12, Palvelin Postmaster wrote: I prepend my spam emails’ subject fields with a specific string to indicate spam, like many do, I presume. Will that string get noticed by bayes and if so, should I do something to prevent it? On 30 May 2018, at 15:21, Matus UHLAR - fantomas wrote: most probably, yes. However, not by your bayes, unless you check for spamminess, tag and check again... On 30.05.18 15:41, Palvelin Postmaster wrote: Yes, forgot to mention I store tagged spam messages and run sa-learn on them to teach spam/ham. it's better to keep spam sign in X-Spam-* headers, which are ignored by spamassassin. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. On the other hand, you have different fingers.
Re: rewrite_header Subject and Bayes
> On 30 May 2018, at 15:21, Matus UHLAR - fantomas wrote: > > On 30.05.18 15:12, Palvelin Postmaster wrote: >> I prepend my spam emails’ subject fields with a specific string to indicate >> spam, like many do, I presume. Will that string get noticed by bayes and >> if so, should I do something to prevent it? > > most probably, yes. > > However, not by your bayes, unless you check for spamminess, tag and check > again... Yes, forgot to mention I store tagged spam messages and run sa-learn on them to teach spam/ham.
Re: rewrite_header Subject and Bayes
On 30.05.18 15:12, Palvelin Postmaster wrote: I prepend my spam emails’ subject fields with a specific string to indicate spam, like many do, I presume. Will that string get noticed by bayes and if so, should I do something to prevent it? most probably, yes. However, not by your bayes, unless you check for spamminess, tag and check again... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Save the whales. Collect the whole set.
rewrite_header Subject and Bayes
Silly question or not, here goes: I prepend my spam emails’ subject fields with a specific string to indicate spam, like many do, I presume. Will that string get noticed by bayes and if so, should I do something to prevent it? -- Palvelin.fi Hostmaster postmas...@palvelin.fi
Re: Tone of emails with subject: 'hey'
Ironically, Gmail's spam filters have filtered every single one of the emails in this thread. :-\ Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop
Re: Tone of emails with subject: 'hey'
On 2018-02-05 22:55, Philip wrote:
> So lately I'm getting LOTS of emails coming directly though the filters so
> most likely time to investigate how to create one.
>
> The subject is always 'hey'
>
> Subject: hey
>
> Date: Mon, 29 Jan 2018 09:07:40 +0300
> From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec9747...@112it4u.ro>
> X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
> MIME-Version: 1.0
> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
>
> Hi josh, my name is Darya and i'm from Russia, but living in the USA. A week
> ago, maybe more, I came across your profile on Facebook and now I wan to know
> you more. I know it sounds a bit strange, but I believe you had something
> like this in your life too :-) If its mutual, email me, this is my email
> danielamar...@rambler.ru and I will send some of my photos also answer any of
> your questions. Waiting for you, XXX Darya
>
> As far as I can see from the different emails:
>
> X-PHP-Originating-Script: 852:class-phpmailer.php
>
> The number is sequential.
>
> 112it4u.ro from the message ID has valid NS entries but the reverse PTR is
> invalid.
>
> The email always starts, 'hi {mailbox name}, and the text is mostly the same
> but the name changes now and then and so does the email address.
>
> Any suggestions on where to start? nOOb here!
Check out http://msbl.org/ This is e-mail addresses blacklist targeting
this type of scam. I have very high score assigned to it and it works
perfectly.
Karol
--
Karol Augustin
ka...@augustin.pl
http://karolaugustin.pl/
+353 85 775 5312
Re: Tone of emails with subject: 'hey'
On 2/5/2018 6:29 PM, John Hardin wrote: Any suggestions on where to start? nOOb here! Do you have Bayes enabled and are you training it? Also do you have KAM.cf? Regards, kAM
Re: Matching To in Subject
On Mon, 5 Feb 2018, Alex wrote: Hi, Is it possible to identify if the Subject contains the sender? You mean like __SUBJ_HAS_FROM_1 ? I realize this probably isn't a significant spam indicator, but I think it would be helpful. From: example.com <r...@multiviscomindo.com> To: mor...@example.com Subject: mor...@example.com You have just 15 hours to verify your account That example is the *recipient*. __TO_IN_SUBJ Neither one is very useful by itself, they would have to be meta'd with other rules, like subject =~ /verify your account/ - which will probably be strong enough signs on their own. I'm also thinking the From with just the domain is a variation of what we saw a few weeks ago with the attempt to confuse the sender. -- 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 --- Maxim IV: Close air support covereth a multitude of sins. --- Tomorrow: the first Falcon Heavy test launch
Matching To in Subject
Hi, Is it possible to identify if the Subject contains the sender? I realize this probably isn't a significant spam indicator, but I think it would be helpful. From: example.com <r...@multiviscomindo.com> To: mor...@example.com Subject: mor...@example.com You have just 15 hours to verify your account I'm also thinking the From with just the domain is a variation of what we saw a few weeks ago with the attempt to confuse the sender.
Re: Tone of emails with subject: 'hey'
On Tue, 6 Feb 2018, Philip wrote:
So lately I'm getting LOTS of emails coming directly though the filters so
most likely time to investigate how to create one.
The subject is always 'hey'
Subject: hey
Date: Mon, 29 Jan 2018 09:07:40 +0300
From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec9747...@112it4u.ro>
X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Any SA hits at all? Please provide at a minimum that header; better,
upload the entire message (all headers intact) to someplace like pastebin.
Hi josh, my name is Darya and i'm from Russia, but living in the USA. A week
ago, maybe more, I came across your profile on Facebook and now I wan to know
you more. I know it sounds a bit strange, but I believe you had something
like this in your life too :-) If its mutual, email me, this is my email
danielamar...@rambler.ru and I will send some of my photos also answer any of
your questions. Waiting for you, XXX Darya
This sort of thing I'd expect Bayes to catch.
112it4u.ro from the message ID has valid NS entries but the reverse PTR is
invalid.
I don't know whether DNS checks on the hostname in the message-ID would be
worthwhile...
The email always starts, 'hi {mailbox name}, and the text is mostly the same
but the name changes now and then and so does the email address.
Any suggestions on where to start? nOOb here!
Do you have Bayes enabled and are you training it?
--
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
---
Watch... Wallet... Gun... Knee...-- Denny Crane
---
Tomorrow: the first Falcon Heavy test launch
Tone of emails with subject: 'hey'
So lately I'm getting LOTS of emails coming directly though the filters
so most likely time to investigate how to create one.
The subject is always 'hey'
Subject: hey
Date: Mon, 29 Jan 2018 09:07:40 +0300
From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec9747...@112it4u.ro>
X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi josh, my name is Darya and i'm from Russia, but living in the USA. A
week ago, maybe more, I came across your profile on Facebook and now I
wan to know you more. I know it sounds a bit strange, but I believe you
had something like this in your life too :-) If its mutual, email me,
this is my email danielamar...@rambler.ru and I will send some of my
photos also answer any of your questions. Waiting for you, XXX Darya
As far as I can see from the different emails:
X-PHP-Originating-Script: 852:class-phpmailer.php
The number is sequential.
112it4u.ro from the message ID has valid NS entries but the reverse PTR
is invalid.
The email always starts, 'hi {mailbox name}, and the text is mostly the
same but the name changes now and then and so does the email address.
Any suggestions on where to start? nOOb here!
Phil
Re: Body rules hit on Subject
On Sat, 3 Feb 2018, Alex wrote: Hi, The only "solution" I've ever come up with is to create a meta rule group to account for the Subject hit: body __FOO /foo/ header __SUBJ_FOO Subject =~ /foo/ meta FOO __FOO && !__SUBJ_FOO I have to admit it's annoyed me on occasion that I can't create a single simple rule that ONLY matches on the message body, but TBH it's never been important enough in context for me to even commit the above horror. It seems the the number of times you want to match ONLY the body and not the body+subject is low enough math this workaround is reasonable. I mean, you could have a new category bodyonly, or something, but I doubt it's necessary. Certainly changing the behavior of body now would be a mistake. I've also had a problem when trying to write rules that rely on or otherwise measure the length of the body. A more complicated set of rules are needed for that, if it's even possible/reliable. Q'n'D: header __SUBJ_LENGTHSubject =~ /./ tflags __SUBJ_LENGTHmultiple body__BODY_LENGTH/./ tflags __BODY_LENGTHmultiple Inefficient as hell, but it should work. Better to use eval:check_body_length() if you can, though. -- 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 --- After ten years (1998-2008) of draconian gun control in the State of Massachusetts, the results are in: firearms-related assaults up 78%, firearms-related homicides up 67%, assault-related emergency room visits up 331%. Gun Control does not reduce violent crime. --- 3 days until the first Falcon Heavy test launch
