Re: regexp dealing with display name don't work
On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: To answer John Harding, here are some display names that I want to block : "@ADMIN" "@WEB-SUPPORT" "@SUPPORT ADMIN" "@webmaster" Is the @ at the beginning of the name part in all cases? Try this: header FROM_NAME_PREFIX_ATSIGN From:name =~ /^\@/ -- 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 --- ...the good of having the government prohibited from doing harm far outweighs the harm of having it obstructed from doing good. -- Mike@mike-istan --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: regexp dealing with display name don't work
On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: Hi David, Thank you for your answer. I don't think I have to escape the @ character. You do. It is recognized without being escaped since when my rule is : From:name =~ /@.b/i The period is changing the interpretation of the @ sign. -- 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 --- ...the good of having the government prohibited from doing harm far outweighs the harm of having it obstructed from doing good. -- Mike@mike-istan --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: regexp dealing with display name don't work
On 27 Apr 2018, at 16:27, Joëlle Pfeffer wrote: Hi David, Thank you for your answer. I don't think I have to escape the @ character. Yes, you do, if you want to match a character following it that could be the first character in an unreserved variable name (letter or underscore) or is an existing Perl special variable. The reason '@.' works unescaped is that it cannot be a user-defined variable and it isn't a Perl special variable, so Perl does not parse it as an array variable. It is recognized without being escaped since when my rule is : From:name =~ /@.b/i the display names consisting of @Ab or @Abc hit. It seems as if the character following the @ is not recognized except if it is a full stop. No. You just happened to test a character after the unescaped @ that isn't the first character of the name of any special Perl variable and can't be the first character of a user-defined variable name. It would also work with digits and most other symbols. SpamAssassin rules also must escape $ or %, which are the other characters Perl uses before variable names to indicate that they are variable names. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: Dropping mail
On Fri, 27 Apr 2018 15:18:28 -0500 (CDT) David B Funk wrote: > If you have that many different classes of recipients, just set the > number of allowed recipients/transaction to one and be done with it. That will cause mail failures. It's not *supposed* to, but I know from experience it will. Some MTAs limit the number of retries to a ridiculously low number like 10 or 20 and then give up. Regards, Dianne.
regexp dealing with display name don't work
To answer John Harding, here are some display names that I want to block : "@ADMIN" "@WEB-SUPPORT" "@SUPPORT ADMIN" "@webmaster" I think I already tried to escape the @ character but it didn't work better. I will try again. Cordialement, Joëlle Pfeffer, Cheffe de projet DINSI/Infrastructures Conseil Départemental de Seine-Saint-Denis 33 (0)1 43 93 97 58 Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite sauf autorisation expresse. L'internet ne permettant pas d'assurer l'intégrité de ce message, le Conseil Départemental de Seine-Saint-Denis décline toute responsabilité au titre de ce message, dans l'hypothèse où il aurait été modifié. D'autre part, le Conseil Départemental de Seine-Saint-Denis ne reconnait exclusivement que les délégations de signatures écrites par les personnes habilitées et ne peut donc être engagé par un message électronique
Re: regexp dealing with display name don't work
Hi David, Thank you for your answer. I don't think I have to escape the @ character. It is recognized without being escaped since when my rule is : From:name =~ /@.b/i the display names consisting of @Ab or @Abc hit. It seems as if the character following the @ is not recognized except if it is a full stop. However I will try to escape the @. I think I tried it among many other things and it didn't worked but I will try again. Cordialement, Joëlle Pfeffer, Cheffe de projet DINSI/Infrastructures Conseil Départemental de Seine-Saint-Denis 33 (0)1 43 93 97 58 - Mail original - De: "David B Funk" À: "Joëlle Pfeffer" Cc: users@spamassassin.apache.org Envoyé: Vendredi 27 Avril 2018 22:09:01 Objet: Re: regexp dealing with display name don't work On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: > I have progressed. > > If my rule is > header REGLE_HF002 From:name =~ /@A/i > > e-mails containing > From: @A > or > From: "@AB" > or > From: "@Ab" > are not blocked > > but if my rule is > header REGLE_HF002 From:name =~ /@.b/i > > e-mails containing > From: "@Ab" > or > From: "@ABc" < jopfef...@free.fr > > are blocked [snip..] If you want to match a literal '@' in a SA regex you need to escape it. Try: header REGLE_HF002 From:name =~ /\@a/i (note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't make sense). -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{ Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite sauf autorisation expresse. L'internet ne permettant pas d'assurer l'intégrité de ce message, le Conseil Départemental de Seine-Saint-Denis décline toute responsabilité au titre de ce message, dans l'hypothèse où il aurait été modifié. D'autre part, le Conseil Départemental de Seine-Saint-Denis ne reconnait exclusivement que les délégations de signatures écrites par les personnes habilitées et ne peut donc être engagé par un message électronique
Re: Dropping mail
On Fri, 27 Apr 2018, Dianne Skoll wrote: On Fri, 27 Apr 2018 14:39:43 -0500 (CDT) David B Funk wrote: [snip] Define two classes of recipients: class A == all users who want everything class B == all users who want "standard" filtering This works if you have a limited number of classes, but in some cases users can make their own rules and settings so the number of classes can be the same as the number of RCPTs. Even in the two-class case, there's still a delay for the subsequent class(es). If you have that many different classes of recipients, just set the number of allowed recipients/transaction to one and be done with it. The delay is entirely up to the sending side, they could immediately retry the subsequent recipients. I was just trying to suggest a solution to your conundrum that didn't require you to drop messages. I didn't say it was optimal, just avoiding the loss of messages. -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: regexp dealing with display name don't work
On Fri, 27 Apr 2018, David B Funk wrote: (note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't make sense). ...it makes precisely as much sense as /\@a/i does... :) -- 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 --- Teach a man to fish, and he'll eat for life. Give him someone else's fish, and he'll vote for you. --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: regexp dealing with display name don't work
On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A or From: "@AB" or From: "@Ab" are not blocked but if my rule is header REGLE_HF002 From:name =~ /@.b/i e-mails containing From: "@Ab" or From: "@ABc" < jopfef...@free.fr > are blocked [snip..] If you want to match a literal '@' in a SA regex you need to escape it. Try: header REGLE_HF002 From:name =~ /\@a/i (note the trailing 'i' makes the regex be case-insenstive so /\@A/i doesn't make sense). -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: regexp dealing with display name don't work
On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A < jopfef...@free.fr > or From: "@AB" < jopfef...@free.fr > or From: "@Ab" < jopfef...@free.fr > are not blocked but if my rule is header REGLE_HF002 From:name =~ /@.b/i e-mails containing From: "@Ab" < jopfef...@free.fr > or From: "@ABc" < jopfef...@free.fr > are blocked If you *are* explicitly looking for @-sign in the from name, you need to escape the @ sign: warn: (Global symbol "@I" requires explicit package name (did you forget to declare "my @I"?) at /home/jhardin/develop/spamassassin/testing/test.cf, rule __FROM_NAME_TEST, line 1.) Try this: header REGLE_HF002 From:name =~ /\@A/i -- 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 --- Teach a man to fish, and he'll eat for life. Give him someone else's fish, and he'll vote for you. --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: regexp dealing with display name don't work
On Fri, 27 Apr 2018, Joëlle Pfeffer wrote: I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A < jopfef...@free.fr > or From: "@AB" < jopfef...@free.fr > or From: "@Ab" < jopfef...@free.fr > are not blocked but if my rule is header REGLE_HF002 From:name =~ /@.b/i e-mails containing From: "@Ab" < jopfef...@free.fr > or From: "@ABc" < jopfef...@free.fr > are blocked Are you specifically looking for from name that has an @-sign in it? Please provide a complete example of a real From header that you want to match. -- 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 --- You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered. -- Lyndon B. Johnson --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: Dropping mail
On Fri, 27 Apr 2018 14:39:43 -0500 (CDT) David B Funk wrote: [snip] > Define two classes of recipients: >class A == all users who want everything >class B == all users who want "standard" filtering This works if you have a limited number of classes, but in some cases users can make their own rules and settings so the number of classes can be the same as the number of RCPTs. Even in the two-class case, there's still a delay for the subsequent class(es). Regards, Dianne.
Re: Dropping mail
On Fri, 27 Apr 2018, Dianne Skoll wrote: Hi, I have reluctantly come to the conclusion that in some cases, it is necessary to silently drop spam rather than reject it. This is the situation: An email comes in for two recipients in one SMTP trasaction (ie, a MAIL, two RCPTs and then DATA). One recipient's rules say to accept. The other recipient's says to reject. You can't reject post-DATA because then it looks like both recipients received the mail. You can accept and create a failure message for one recipient, but then you risk generating backscatter. You can tempfail all but the first RCPT to force the message to be split up into individual messages per recipient, allowing you to accept or reject individually. But this will delay mail and possibly cause it not to be delivered if there are many recipients and the sending relay is impatient. So I reluctantly conclude that in all but the smallest of installations, dropping the mail for the recipient whose rules say to do so is the best thing to do. There have been SMTP extensions proposed to combat this. I recall an extension that had you issue RCPTs until one of the RCPTs was accepted, then DATA, then additional RCPTs with a "also send the foregoing to this one" keyword so you could have per-recipient data filtering, but of course spammers could not be obliged to use the extension. :( One possible way to deal with this situation (which would require some additional complexity on the server and require good behavior on the senders) is: Define two classes of recipients: class A == all users who want everything class B == all users who want "standard" filtering At 'RCPT' phase of the SMTP transaction note if the first valid recipient is class "A" or class "B", set a flag to remember it. For each subsequent valid recipient see if their class is the same as the first recipient. If not then return a "452 Too many recipients" reply code for that one and all subsequent valid recipients. Ideally the sender should then move on to the DATA phase, complete the processing for the first batch of recipients, and then try again for the remainder. If all goes well, this should split up the different classes of recipients into separate SMTP transactions allowing for appropriate processing with out loss. Your classifications can be expanded upon to meet your site requirements but the processing logic should be the same. -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
regexp dealing with display name don't work
I have progressed. If my rule is header REGLE_HF002 From:name =~ /@A/i e-mails containing From: @A < jopfef...@free.fr > or From: "@AB" < jopfef...@free.fr > or From: "@Ab" < jopfef...@free.fr > are not blocked but if my rule is header REGLE_HF002 From:name =~ /@.b/i e-mails containing From: "@Ab" < jopfef...@free.fr > or From: "@ABc" < jopfef...@free.fr > are blocked I can only note that the character following the @ is not efficient except when it is a full stop but I don't understand why. Cordialement, Joëlle Pfeffer, Cheffe de projet DINSI/Infrastructures Conseil Départemental de Seine-Saint-Denis 33 (0)1 43 93 97 58 Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite sauf autorisation expresse. L'internet ne permettant pas d'assurer l'intégrité de ce message, le Conseil Départemental de Seine-Saint-Denis décline toute responsabilité au titre de ce message, dans l'hypothèse où il aurait été modifié. D'autre part, le Conseil Départemental de Seine-Saint-Denis ne reconnait exclusivement que les délégations de signatures écrites par les personnes habilitées et ne peut donc être engagé par un message électronique
Dropping mail
Hi, I have reluctantly come to the conclusion that in some cases, it is necessary to silently drop spam rather than reject it. This is the situation: An email comes in for two recipients in one SMTP trasaction (ie, a MAIL, two RCPTs and then DATA). One recipient's rules say to accept. The other recipient's says to reject. You can't reject post-DATA because then it looks like both recipients received the mail. You can accept and create a failure message for one recipient, but then you risk generating backscatter. You can tempfail all but the first RCPT to force the message to be split up into individual messages per recipient, allowing you to accept or reject individually. But this will delay mail and possibly cause it not to be delivered if there are many recipients and the sending relay is impatient. So I reluctantly conclude that in all but the smallest of installations, dropping the mail for the recipient whose rules say to do so is the best thing to do. There have been SMTP extensions proposed to combat this. I recall an extension that had you issue RCPTs until one of the RCPTs was accepted, then DATA, then additional RCPTs with a "also send the foregoing to this one" keyword so you could have per-recipient data filtering, but of course spammers could not be obliged to use the extension. :( Regards, Dianne.
Re: dropping other's email(s) as a "best practice" for hosted email?
On Fri, 27 Apr 2018, L A Walsh wrote: Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. That used to happen on poorly implemented mailing lists -- a delivery error would be bounced back to the email list as a reply that would get sent out to all the subscribers. *used* to happen. Such mis-coding should have been fixed a long time ago, and if there's ML software that still does that it is *not* the receiving MTA's problem or fault. On a list with 10,000 subscribers or more with maybe ~1000 messages/day, how many people would be getting back mail-delivery failures that they could do nothing about. These days, none should. The ML software should have mechanisms to capture those delivery problem reports and disable that subscriber, and/or notify them that list messages are failing (though notifying them isn't guaranteed if there are problems delivering to them...). If a given user wants emails to be dropped at the border I echo the request that you stop misusing the term "dropped" when you mean "rejected". -- 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 --- Teach a man to fish, and he'll eat for life. Give him someone else's fish, and he'll vote for you. --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: dropping other's email(s) as a "best practice" for hosted email?
Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. On 27.04.18 09:32, L A Walsh wrote: If a given user wants emails to be dropped at the border -- that would be fine. *I* would not mind configuring a filter that dropped some incoming emails, but if it is going to make the incoming mail server too slow to handle per-user options, it might not be doable. once more: STOP calling rejection a dropping. Rejecting is NOT dropping. They are two different things. If you try to hand me an envelope, and I will refuse to take it, It is NOT the same as if I took it and dropped to trash. The envelope stays in your hands and you are responsible for it. If you drop it later, it's your problem, not mine. You are blaming us for how internet communication works for years. Your rant is completely useless. -- 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. 2B|!2B, that's a question!
Re: dropping other's email(s) as a "best practice" for hosted email?
Alan Hodgson wrote: Rejecting the message during receipt causes the sending server to generate a bounce. If it's at all functional. That used to happen on poorly implemented mailing lists -- a delivery error would be bounced back to the email list as a reply that would get sent out to all the subscribers. Would it even be practical to bounce a deliver failures back to the original poster of the message to the list? On a list with 10,000 subscribers or more with maybe ~1000 messages/day, how many people would be getting back mail-delivery failures that they could do nothing about. Many or most hosted email services provide a user-controllable spam filter. The problem is, if an email is not accepted, rather than being delivered and filtered by the "per user-filtering", the user can not tailor such filters to their own mail. It preempts the oft needed ability for the user to judge what is spam and what is not. I am not suggesting sending a "bounce back message", but have the default be to do what the user configures via their account options. If a given user wants emails to be dropped at the border -- that would be fine. *I* would not mind configuring a filter that dropped some incoming emails, but if it is going to make the incoming mail server too slow to handle per-user options, it might not be doable. Even without per-user options, many servers that try to do filtering between reading the message and sending a response end up having periods of unacceptable response time. NTL, running filters over incoming email when the user has explicitly ask for unfiltered email is reprehensible. I do my own email filtering on my home server. I find ISP's doing their own filtering and modification of incoming user messages based on their criteria to be a very bad situation. Also, someone mentioned safe-harbor provisions. Those were designed for websites where material is hosted for public view on the host's computers. The wording in the US act applies to those who *publish information by others* (like a website). It doesn't apply to pass-through services like ISP's and email services. Email and ISP service has been more held in line with services provided by the phone company -- that of common carrier status that is predicated upon NOT inspecting content as it travels through a carrier's equipment. That said, different countries will have different laws, and the laws are changing as email-provider demonstrate their ability to monitor and filter real-time communications. Some countries are moving to have email providers be responsible for filtering or allowing discussion of illegal acts. That's not a good direction to be going, IMO.
configuring spamassassin
sorry if this question is a bit vague but i am currently unable to ssh into my server to get more info. i am using centos 7 and i have set up spamassassin training by scanning messages which are moved into or out of the junk folder. it seems to work ok because database entries are being created in the mysql database. however it seems to have little or no effect on the amount of spam coming through. is it possible it is training but not actually using the training data during the scanning? also i think it was set up to train separately for each individual user. it seems like having common training where everyone's emails are scanned using the same bayes data would be more logical as all the email users are in the same business. is this just a matter of setting a flag?
Re: FP with URI_TRY_3LD on get.adobe.com
On Fri, 27 Apr 2018, Sebastian Arcus wrote: On 27/04/18 10:49, Sebastian Arcus wrote: I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com"; Would it be possible to add some exception to this rule - as many legitimate emails containing invoice attachments in pdf include the above url in the body. It also appears to not like some DHL url's for some reason: Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "https://mybill.dhl.com"; my{mumble}.mumble.com is targeted. I'll think about that one; the rule isn't scored highly and I could see that helping out to detect DHL phishing. -- 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 --- the Internal Revenue Service has an "impressive history ... of storing [data] carelessly, leaking data through every possible conduit, and hiring employees who appear to only marginally prefer a career in tax collection over knocking over liquor stores." -- Reason's J.D. Tuccille --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: FP with URI_TRY_3LD on get.adobe.com
If this is causing the entire mail to be flagged as SPAM, we need to see the entire FP not just a hit on one rule. That rule has a max 0.8 score. Though it does appear to be hitting on more than intended though. Anyone know what it is supposed to hit because I think it might be hitting on a lot more than intended? Regards, KAM -- Kevin A. McGrail Asst. Treasurer & VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Fri, Apr 27, 2018 at 6:03 AM, Sebastian Arcus wrote: > > On 27/04/18 10:49, Sebastian Arcus wrote: > >> I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in >> the body of emails: >> >> Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> >> got hit: "http://get.adobe.com"; >> >> Would it be possible to add some exception to this rule - as many >> legitimate emails containing invoice attachments in pdf include the above >> url in the body. >> > > It also appears to not like some DHL url's for some reason: > > Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==> > got hit: "https://mybill.dhl.com"; >
Re: FP with URI_TRY_3LD on get.adobe.com
On Fri, 27 Apr 2018, Sebastian Arcus wrote: I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com"; Would it be possible to add some exception to this rule - as many legitimate emails containing invoice attachments in pdf include the above url in the body. Fixed. -- 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 --- the Internal Revenue Service has an "impressive history ... of storing [data] carelessly, leaking data through every possible conduit, and hiring employees who appear to only marginally prefer a career in tax collection over knocking over liquor stores." -- Reason's J.D. Tuccille --- 4 days until May Day - Remember 110 million people murdered by Communism
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On Fri, 27 Apr 2018, Matus UHLAR - fantomas wrote: On 26.04.18 13:41, L A Walsh wrote: To my way of thinking, dropping someone else's email, telling the sender the email is being rejected for having spam-like characteristics and telling the recipient nothing seems like it might have legal liability for the for the user potentially missing vital email. Refusing to take a mail is not dropping. Noone is required by any means to accept anything because there may be many reasons a mail can't be accepted. The place where dropping is a risk is if the next-to-last hop is Dain Bramaged and doesn't handle SMTP rejects properly. But that isn't your server's fault, it's the poor service the sender's using. (unfortunately the sender may not know of that bad link in their chain). Also it's entirely possible that the NtLH server may strip off useful info from the SMTP reject message and leave the poor sender wondering what went wrong. (I'm looking at you MS Exchange). -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: Anti Phish Rules
On 27/04/2018 17:53, Matus UHLAR - fantomas wrote: > On 27.04.18 06:51, Noel Butler wrote: > >> I suspect Nick is still using and referring to mailscanner (which is/was >> written in perl), it has/had this ability, I (like a good few of the >> names around here) used it back in the day as well, until it became >> clear it was abandonware, and did not like certain newer versions of >> perl causing exits after each scan, mind you, I did dump it for amavisd >> back around 2008/9/10, that said I liked that function, and rarely >> noticed any FP's, my memorys hazy, but IIRC, it disarmed the links, >> rather than take any scoring action... I might be wrong though, like I >> said, its been along time. > > I believe that the same arguments (need for hugt whitelist) could apply for > mailscanner too. I certainly never needed to whitelist anyone and we processed millions of messages a day at that ISP but as I said, it disarmed it, stopping you from clicking on it, not marking it as spam or such, which might require more thought > I have noticed discussion about this request/issue many times in this > mailing list, still the same conclusions, so I wanted to point out to > problems rather than telling the OP "go search list archives". > > Note that I don't like this kind of mismatches too and I would invite having > such plugin in SA > > I would maybe even avoid initial whitelist to force organizations stop using > such mismatched URLs (should be safe with not too high scores). Thats the whole problem, idiotic companies who send links like that deserve to get blocked/spam-binned, but everybody runs around creating whitelists, so why woulld they fix their shit, they have no incentive to when people whitelist them. I've never cared who you are, a ma 'n pa op shop, a govt dept, or huge corporate, like BP, or whoever, you dont get whitelisted by me, and my users know that, they know not to bitch to us about it, but to the senders, been my way for a very long time, works for me ;) -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Re: Anti Phish Rules
On 27/04/2018 07:27, David Jones wrote: > MailScanner became very mature and didn't need any major updates for years > then Jules turned it over to Jerry Benton who had a commercial product based > on it. It's still being updated and runs fine now on systemd-based OSes and > newer versions of Perl. One of our customers, Shawn Iversion, is helping > Jerry maintain MailScanner now as part of his EFA project. > https://efa-project.org/ > > - > > FROM: Kevin Miller > SENT: Thursday, April 26, 2018 4:16 PM > TO: users@spamassassin.apache.org > SUBJECT: RE: Anti Phish Rules > > It's not abandonware - Jules handed it off to some other folks that are > actively putting out new versions. As a matter of fact one came out not too > long ago. MailWatch for MailScanner is also being actively developed still. > > Latest/greatest is available at www.mailscanner.info [1] for anyone wanting > to check it out. > > ...Kevin > > -- > > Kevin Miller > > Network/email Administrator, CBJ MIS Dept. > > 155 South Seward Street > > Juneau, Alaska 99801 > > Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 > > FROM: Noel Butler [mailto:noel.but...@ausics.net] > SENT: Thursday, April 26, 2018 12:51 PM > TO: users@spamassassin.apache.org > SUBJECT: Re: Anti Phish Rules > > On 26/04/2018 18:12, Matus UHLAR - fantomas wrote: > >> On 26.04.18 18:00, Nick Edwards wrote: >> >> We've been using a separate product to do this, but it struck me, maybe >> spamassassin can do this easier (or without having to call yet another >> binary to run as can over mails) >> >> Rules that look at URLs in a html message href and src tags, check the "A" >> tag to see if there is a URL there, and if they do not match, consider it >> a phis so apply said phis score to the message. >> >> Has anyone done this? module even? >> >> the main problem: may non-spam senders do that, see: >> >> https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule >> >> and further the discussion in linked bug: >> >> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255 > > I suspect Nick is still using and referring to mailscanner (which is/was > written in perl), it has/had this ability, I (like a good few of the names > around here) used it back in the day as well, until it became clear it was > abandonware, and did not like certain newer versions of perl causing exits > after each scan, mind you, I did dump it for amavisd back around 2008/9/10, > that said I liked that function, and rarely noticed any FP's, my memorys > hazy, but IIRC, it disarmed the links, rather than take any scoring action... > I might be wrong though, like I said, its been along time. > > -- > > Kind Regards, > > Noel Butler > > This Email, including any attachments, may contain legally privileged > information, therefore remains confidential and subject to copyright > protected under international law. You may not disseminate, discuss, or > reveal, any part, to anyone, without the authors express written authority to > do so. If you are not the intended recipient, please notify the sender then > delete all copies of this message including attachments, immediately. > Confidentiality, copyright, and legal privilege are not waived or lost by > reason of the mistaken delivery of this message. Only PDF [2] and ODF [3] > documents accepted, please do not send proprietary formatted documents It was very mature until it broke with later perls, each child would exit after a scan, as I said this was back some 8/9 years ago, so if its maintained again by 2018 one would hope those bugs are eliminated, but, it caused a few grief, and Jules was MIA (yeah I recall him having health issues) which didnt help those affected by the nasty child exit bugs, amavisd suits us fine, though I do miss the phishing disarming, i'm sure one can coddle up some decent SA rules if one wanted to. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [2] and ODF [3] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.mailscanner.info [2] http://www.adobe.com/ [3] http://en.wikipedia.org/wiki/OpenDocument
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On Thu, 26 Apr 2018 13:41:05 -0700 L A Walsh wrote: > To my way of thinking, dropping someone else's email, > telling the sender the email is being rejected for having > spam-like characteristics and telling the recipient nothing > seems like it might have legal liability for the for the > user potentially missing vital email. It all depends on the contract between the service provider and the customer. If the service provider puts something in to the effect that it will make best-effort attempts to deliver mail but is not responsible for lost mail, then I doubt there's any legal liability. For example, Google's Terms of Service say the following (in all-caps) Other than as expressly set out in these terms or additional terms, neither Google nor its suppliers or distributors make any specific promises about the services. For example, we don’t make any commitments about the content within the services, the specific functions of the services, or their reliability, availability, or ability to meet your needs. We provide the services “as is”. Some jurisdictions provide for certain warranties, like the implied warranty of merchantability, fitness for a particular purpose and non-infringement. To the extent permitted by law, we exclude all warranties. They also have a limitation of liability clause that limits their liability to the amount paid to use the services. Regards, Dianne.
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On 2018-04-26 (14:41 MDT), L A Walsh wrote: > > To my way of thinking, dropping someone else's email, telling the sender the > email is being rejected for having spam-like characteristics and telling the > recipient nothing seems like it might have legal liability for the for the > user potentially missing vital email. I agree that once the mail has been ACCEPTED the recent has to either receive the mail or know why the mail isn't there. For example, most spammy mail is delivered to a users Junk box, where they have a week to check it for mistagged mail, but after a certain threshold, users know that the email will be discarded (scoring over 10 in my case). However, this is very rare because most mail that is that spammy is rejected at the SMTP phase. > It also would seem to violate what used to be a basic expectation of internet > email -- that it is either delivered to the recipient's inbox OR you'll > receive a non-delivery notification (a "bounce"). Or you will receive a rejection immediately. Thin about it this way, if you send an email to da...@example.com and there is no such account because you intended to send it to d...@example.com you do not get an NDN, you get a rejection. -- I want a party where all the women wear new dresses and all the men drink beer. -- Jason Gaes
Re: FP with URI_TRY_3LD on get.adobe.com
On 27/04/18 10:49, Sebastian Arcus wrote: I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com"; Would it be possible to add some exception to this rule - as many legitimate emails containing invoice attachments in pdf include the above url in the body. It also appears to not like some DHL url's for some reason: Apr 27 11:02:05.148 [32339] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "https://mybill.dhl.com";
FP with URI_TRY_3LD on get.adobe.com
I am getting some FP's with URI_TRY_3LD hitting the url get.adobe.com in the body of emails: Apr 27 10:45:39.330 [32173] dbg: rules: ran uri rule URI_TRY_3LD ==> got hit: "http://get.adobe.com"; Would it be possible to add some exception to this rule - as many legitimate emails containing invoice attachments in pdf include the above url in the body.
Re: dropping other's email(s) as a "best practice" for hosted email? (was: "anyone recognize these headers? ...")
On 26.04.18 13:41, L A Walsh wrote: To my way of thinking, dropping someone else's email, telling the sender the email is being rejected for having spam-like characteristics and telling the recipient nothing seems like it might have legal liability for the for the user potentially missing vital email. Refusing to take a mail is not dropping. Noone is required by any means to accept anything because there may be many reasons a mail can't be accepted. For example, mail server that it out of disk space cannot accept a mail thus the only possibility is to refuse accepting it. Dropping mail is the case where mailserver accepts mail and does not deliver it, nor send a bounce. It also would seem to violate what used to be a basic expectation of internet email -- that it is either delivered to the recipient's inbox OR you'll receive a non-delivery notification (a "bounce"). I have no idea where did you get this expectation - your assumption is false. Nearly (if not completely) all mailservers tend to refuse accept mail even from the client, if: - the mail is over allowed size - the sending address is invalid, undeliverable or forged - the mail contains virus, phish, malware or otherwise dangerous content especially in the case the sending address is invalid or undeliverable, it is impossible impossible to send bounce to the sending address. When the address is forged, those bounces would go to a innocent victim. There are many reasons why mailserver (even your submission server) could refuse message. If your submission server accepts a message, it of course SHOULD send a bounce when the recipient's server refuses it (exemptions named above) Note that in this case the recipients server refuses to handle a message, and instead of bouncing, sending the bounce is up to your submission server. I hope some of those who think it was a good practice to delete a user's email (because they think it is malware) might rethink that practice. I hope you now understand what is the difference between deleting and refusing a mail and won't blame us for way how mail system works (and always worked), just because you have misunderstood (or assumed) it. I didn't realize email was no longer considered unreliable afaik e-mail was NEVER considered reliable, mostly because of reasons mentioned above. -- 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. "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
Re: Anti Phish Rules
On 26.04.18 18:00, Nick Edwards wrote: We've been using a separate product to do this, but it struck me, maybe spamassassin can do this easier (or without having to call yet another binary to run as can over mails) Rules that look at URLs in a html message href and src tags, check the "A" tag to see if there is a URL there, and if they do not match, consider it a phis so apply said phis score to the message. Has anyone done this? module even? On 26/04/2018 18:12, Matus UHLAR - fantomas wrote: the main problem: may non-spam senders do that, see: https://wiki.apache.org/spamassassin/AntiPhishFakeUrlRule and further the discussion in linked bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=4255 On 27.04.18 06:51, Noel Butler wrote: I suspect Nick is still using and referring to mailscanner (which is/was written in perl), it has/had this ability, I (like a good few of the names around here) used it back in the day as well, until it became clear it was abandonware, and did not like certain newer versions of perl causing exits after each scan, mind you, I did dump it for amavisd back around 2008/9/10, that said I liked that function, and rarely noticed any FP's, my memorys hazy, but IIRC, it disarmed the links, rather than take any scoring action... I might be wrong though, like I said, its been along time. I believe that the same arguments (need for hugt whitelist) could apply for mailscanner too. I have noticed discussion about this request/issue many times in this mailing list, still the same conclusions, so I wanted to point out to problems rather than telling the OP "go search list archives". Note that I don't like this kind of mismatches too and I would invite having such plugin in SA I would maybe even avoid initial whitelist to force organizations stop using such mismatched URLs (should be safe with not too high scores). -- 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. REALITY.SYS corrupted. Press any key to reboot Universe.