Re: [Sare-users] painting everybody in Taiwan with the same brush
On Thu, 2010-01-28 at 10:35 +0800, jida...@jidanni.org wrote: > Yes, but that's beside the point. That is not solving the bad thing > you guys are doing. Eh? stopping spammers is a bad thing now hey... > MM> The world isn't perfect and the only way to get things changed is to > complaint > MM> and/or do something about it yourself. But to blanket criticise rules that > MM> many sites are using worldwide doesn't really make sense to me. > > You guys are doing something wrong. Maybe you think that every country > is like the USA or something. You blew it. Your rules are wrong. oh right we bad, bad bad bad, how DARE we put measures in place to stop spamming scum > > Yes I am using the wires of that Telephone Company. But at the first > chance my mail gets, it leaves those wires and heads for the smarthost > in the USA in order to cleanse its sins of having come from an > unfamiliar country. But for you guys, once you are a Negro you are > always a Negro or something. Please fix your rules. You are demanding > one use certain physical carriers irrespective of ISP. what racist rot. I too are not an American (NEWSFLASH: like at least half or more of this list). a person can not change the colour of their skin (WOW about the only thing you said that did not make me piss myself in laughter) however a country that does not care about its residents spamming CAN change, yet TW has failed to do so. Even China has in recent years taken great steps to clean up their act, if you want change, it must start at the top, petition your government to get off its lazy ass and do something about its spamming residents, clean up their act, and in time to come TW, like CN has recently found, many places just might once again start accepting your mail. Don't you dare sit there having a childish dummy spit accusing everyone here to be wrong by denying access or adding a substantial score to a well known spammer friendly country.
Re: blog article on 3.3.0
On Thu, 2010-01-28 at 12:53 -0500, Bowie Bailey wrote: > Alex wrote: > > Hi, > > > > > >> http://www.returnpath.net/blog/2010/01/spamassasin-rarely-misses.php > >> > >> Yeah, it's partly self-serving, but that's what corporate blogs are for. > >> The people who read this > >> blog are mostly marketers with very little exposure to the open source > >> community, so this > >> should help them understand a bit more of how the real email ecosystem > >> operates. > >> > > > > Yes, good article. A little difficult to read, though. Is there > > something you're doing with the fonts to make them so light? > > > > The font is very small (CTRL-+ helped here), but it's so light I > > couldn't read it. > > > > I didn't have a problem. The font is normal-size black on white for me > in both IE and Firefox (WinXP and Linux). It is light grey on white, though it is "just" readable here due the angle of my monitor. I have the truetype fonts installed, maybe this is what Alex uses too and causes the issue?
Re: painting everybody in Taiwan with the same brush
On Thu, 2010-01-28 at 13:59 -0500, Adam Katz wrote: > SpamCop sister-site SenderBase seems to indicate at > http://www.senderbase.org/senderbase_queries/detaildomain?search_string=hinet.net > that there isn't much traffic coming from IPs whose rDNS contain > 'dynamic.hinet.net' anyway, so it appears they've cleaned up. I see hundreds and hundreds of these a day here, though we deny access to all dynamic looking hostmarks via mitler-regex rules on the MTA's as well as outright deny no rDNS, so spam from them is in fact non existent. > I side with the complainer on this one. The rule is too broad, and, > like most SARE rules, it is probably stale. In its day, it was a very welcome rule, because as pointed out, spammers do have brains and know how to relay through "seemingly trusted hosts". I also know as many sys admins who outright block all of hinet in access file's, It is a decision I don't agree with, but each network must make its own decision based upon their own requirements.
Re: Hostkarma whitelist FP
On Mon, 2010-02-01 at 10:52 -0800, Marc Perkel wrote: > > > Mike Cardwell wrote: > > > On 01/02/2010 17:31, Marc Perkel wrote: > > > > > > > > > Yep - sutterhealth.org is a hospital. Making sure good email gets > > > through is more important than a little bit of occasional spam. > > > > > > > > > http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists > > > > "And if you never send spam we want you to be on our whitelist." > > > > Please follow your own listing criteria and remove the host from your > > whitelist. Alternatively, update your documentation to reflect the real > > listing criteria. As it stands, I can understand sutterhealth.org being > > on your NOBL list, but not on a list which you define as hosts which > > "never send spam". > > > > > > > Never is a fuzzy line when it comes to institutions like hospitals. It > a matter of what is important and to us at Junk Email Filter making > sure medical email is delivered is far more important that blocking a > few spams. Never means exactly that, never, so your public documentation does need modification to reflect that your version of never doesn't equal the dictionaries and most peoples understanding of it. I can see your point though, however, and it seems if you apply it to one, questions remain as to who else you apply it to, it's just as well all white lists in SA are scored 0 on all mail servers I control so you don't/wont/can't decide white listing policies here. (No , im not totally anal, hospitals here all use domain name of health.$state.gov.au... they bypass SA and MTA tests altogether.)
SA 3.3 w/MailScanner
Hi, Is anyone else using this combination, and who uses "attachment" to, in particular for low score spam, seeing no results in the initial warning.txt, as ... (no report template found) instead of the SA report? If you do, I ask you to report it if you're on mailscanner list, as I am unable to. This seemed to stop working for us on my own pvt server and a corporate one that I upgraded to 3.3 on SA 3.2 servers it works fine still. Yes self appointed list cops, I know this is not a SA issue, but it involves it :) and as stated I am unable to communicate with them or JKF.
Re: SA 3.3 w/MailScanner
On Fri, 2010-02-05 at 13:38 -0800, Ted Mittelstaedt wrote: > We are currently runing Mailscanner 4.79.4-1 plus SA 3.2.5 with > mailwatch 1.0.4 as a front end, sendmail as the mta, on freebsd 7.2 > on one of the servers we setup for a cusstomer. We do not use procmail. > Thanks, but your using 3.2.5, the issue only appeared with 3,3.0 Guess we'll have to consider alternatives to resolve this, as its rather annoying to users, telling them to read the headers to see the scores and reason doesn't wash with dummies :) Cheers
Re: SA 3.3 w/MailScanner
On Fri, 2010-02-05 at 14:57 -0800, Ted Mittelstaedt wrote: > > > > Thanks, but your using 3.2.5, the issue only appeared with 3,3.0 > > I knew that, I just wanted to let you know that you wern't the only > ones out there running this combo. > > Ted > > > Guess we'll have to consider alternatives to resolve this, as its rather > > annoying to users, telling them to read the headers to see the scores > > and reason doesn't wash with dummies :) > > > > Ted, do you use the URI's in your configuration? I notice MailScanner doesnt do half the SA stuff, including them, I have verified the issue is not SA however, because amavisd-new does all tests, so I guess its all OT for this list now :) Cheers
RES: Re: SA 3.3 w/MailScanner
On Fri, 2010-02-05 at 13:58 +1000, Noel Butler wrote: > Hi, > > Is anyone else using this combination, and who uses "attachment" to, > in particular for low score spam, seeing > no results in the initial warning.txt, as ... > > (no report template found) > instead of the SA report? > > If you do, I ask you to report it if you're on mailscanner list, as I > am unable to. > This seemed to stop working for us on my own pvt server and a > corporate one that I upgraded to 3.3 > on SA 3.2 servers it works fine still. > > Yes self appointed list cops, I know this is not a SA issue, but it > involves it :) and as stated I am unable to > communicate with them or JKF. > This issue is resolved. Perl modules required by mailscanner updated to current via CPAN combined with SA upgrade saw mailscanners search paths tightened up for searching local state dir. Replacing the old /var/lib setting (which has worked for best part of a decade) with /var/lib/spamassassin resolved this (and it seems other) issues. mailscanner --debug --debug-sa still saw the correct path which is why I never picked this up sooner, but mailscanner processing no longer did for whatever reason, prompted to look deeper due to at least two other people having serious issues ( one of which was being laughed at and accused of being clueless on the mailscanner list, and I know whats its like to not get help there, too many people there are more worried about someone top posting or sulking because they posted in HTML than actually helping with the issue *sigh*).
Re: [Emerging-Sigs] SIG: SpamAssassin Milter Plugin Remote Arbitrary Command Injection Attempt
On Tue, 2010-03-09 at 16:33 +0200, Henrik K wrote: > On Tue, Mar 09, 2010 at 08:22:41AM -0600, David Morton wrote: > > > > What exactly *DO* you want?? > > He's a well known troll here, yet for some reason people want to amuse him > and fill out the list with pointless arguments. PLEASE ignore him, since > noone has taken the job of unsubscribing him yet. > He has a point though, and why is it when people don't agree with someone the troll label comes out, FFS get over your selves. People always only half read, and then go half cocked, its called life, get used to it. FWIW I agree about the well known postfix fanbois, it is decent software, but its not the pot of gold they think it is, it lacks many features and I was told where to go when suggesting them. I also got no response or help from Wietse or any other 'in the know' people with a query recently, but because I considered it a bug, I guess thats why :) <>
Re: SORBS
Only BT can request that delisting, sorry, but you are wasting your time. On Tue, 2010-04-20 at 14:40 +0100, Nigel Frankcom wrote: > On 20 April 2010 14:13, corpus.defero wrote: > > On Tue, 2010-04-20 at 14:04 +0100, Nigel Frankcom wrote: > >> Hi All, > >> > >> Am I the only one incabale of figuring out the SORBS interface? > >> > >> I'm told by various mailserver that sorbs is blocking me (including > >> this list hence mailing from my gmail account). > >> > >> When I log on to sorbs, give my details I get a nice email back saying: > >> > >> $Id: Act.pm,v 1.16 2006/11/27 03:36:09 lem Exp $ > >> > >> I'm a robot writing you on behalf of the SORBS' admins. The reason > >> you're getting this automated response, is our desire to provide you > >> with consistent and fast responses. I'm prepared to correctly analyze > >> most of the cases appearing in the DUHL queue. > >> > >> You might want to keep your responses as short as possible (and to > >> trim my own responses) to help humans better serve you should the need > >> arise. > >> > >> > >> > >> I'm glad to report that the IP space will be submitted for delisting > >> from the DUHL. > >> > >> Best regards. > >> > >> SORBS > >> > >> It's now Day 6. and I'm still listed. > >> > >> If anyone has any ideas - please let me know? > >> > >> Kind regards > >> > >> Nigel > > > > Since when did the Spamassassin list become a place for people to bitch > > about SORBS ;-) > > > > The link is clear enough - get delisted/support here it is in case you > > can't see it amoungst all that clutter: > > > > http://www.au.sorbs.net/cgi-bin/support > > > > > > > > > 217.36.54.209 listed in the Dynamic IP Space (LAN, Cable, DSL & Dial Ups) > > Following your erudite link... that has been followed at least 4 times > before I get: > > $Id: Act.pm,v 1.16 2006/11/27 03:36:09 lem Exp $ > > I'm a robot writing you on behalf of the SORBS' admins. The reason > you're getting this automated response, is our desire to provide you > with consistent and fast responses. I'm prepared to correctly analyze > most of the cases appearing in the DUHL queue. > > You might want to keep your responses as short as possible (and to > trim my own responses) to help humans better serve you should the need > arise. > > > > I'm glad to report that the IP space will be submitted for delisting > from the DUHL. > > ...And I'm STILL in the damned list > > SORBS seems to have an issue, SORBS scores are used in SA - ergo it is > relevant to this list. > > Again, please, can someone offer a sensible suggestion as to how I > might resolve this problem. Or, a means of not disrupting SA lists, > and suggesting where I may find help relating to my particular issue. > > Nigel
Re: email address forgery
On Thu, 2010-11-11 at 10:07 -0500, Rob McEwen wrote: > On 11/11/2010 9:11 AM, Jeremy Van Rooyen wrote: > > Can anybody explain to me how to do this and how would I be able to > > test it? > > Jeremy, > > I really like to use the following wizard to generate my SPF strings: > > http://www.openspf.org/ > > Scroll down to the section that says "Deploying SPF", enter the domain > name, and click "GO". Then, on the next page, fine tune the answers to > the various questions before submitting the info to generate your SPF > string. Finally, go into your DNS server and, for that domain, add that > string as a TXT record. > *and* as an SPF record type, the TXT method is deprecated, but for time being it's good to use it since there are a lot, and I mean a LOT of outdated DNS servers around that do not support it even today, yes, the fault of the DNS server admin for running antiquated rubbish, but, there's just no telling some people to get with the times. signature.asc Description: This is a digitally signed message part
Re: email address forgery
On Thu, 2010-11-11 at 17:31 -0500, Michael Scheidell wrote: > On 11/11/10 5:13 PM, Noel Butler wrote: > > *and* as an SPF record type, the TXT method is deprecated, > but then again, SA doesn't support SPF record type, only TXT type.. > > Really? I don't use SPF in SA, only MTA, if that's the case, it is a shame that SA also is behind the times. It was years ago SPF type was ratified. Justin: Any plans to change that? signature.asc Description: This is a digitally signed message part
Re: email address forgery
On Thu, 2010-11-11 at 20:07 -0500, Rob McEwen wrote: > On 11/11/2010 7:41 PM, Noel Butler wrote: > > Really? I don't use SPF in SA, only MTA, if that's the case, it is a > > shame that SA also is behind the times. It was years ago SPF type was > > ratified. Justin: Any plans to change that? > > I guess I'm one of those mail admins who is behind the times. But I > don't really care that much because I take the same position as Suresh > Ramasubramanian... that SPF is a failed technology because, for one, it Please keep your usual anti spf rants to yourself, no offence, but it is an official RR, there for it should be supported regardless of if you like or detest it, yes SPF is like a religious war. Oh and for the record I've never seen any problems with forwarding, ever, but YMMV, that is NOT what my post was about. . signature.asc Description: This is a digitally signed message part
Re: email address forgery
On Thu, 2010-11-11 at 19:38 -0600, René Berber wrote: > On 11/11/2010 4:13 PM, Noel Butler wrote: > > > *and* as an SPF record type, the TXT method is deprecated, but for > > time being it's good to use it since there are a lot, and I mean a LOT > > of outdated DNS servers around that do not support it even today, yes, > > the fault of the DNS server admin for running antiquated rubbish, but, > > there's just no telling some people to get with the times. > > What "SPF record type"? > > Using the tools at http://www.openspf.org/ produces the TXT record, and > I don't find any mention to SPF records, on the other hand it says "The > specification has been frozen" talking about the TXT record. http://tools.ietf.org/html/rfc4408 signature.asc Description: This is a digitally signed message part
Re: NJABL is dead?
On Tue, 2010-12-28 at 19:05 -1000, Warren Togami Jr. wrote: > Whoa. Ted please calm down. I think you read too much into this and > are seriously overreacting. I didn't propose immediately replacing > NJABL with like mailspike. I was only pointing out > that NJABL was performing very poorly, to such an extent that you're > better off removing it because it is needlessly using your resources. > In effect my proposal makes nearly zero difference to SpamAssassin's > current performance because these rules are nearly useless. > Makes little difference anywhere, I used it amongst others at MTA level. NJABL used to be good 4 or 5 years back, but in recent years, it rarely gets a hit, it always falls back to spamcop/sorbs/spamhaus signature.asc Description: This is a digitally signed message part
Re: Off topic: best RBLs to use to block at smtp connection?
On Thu, 2011-01-06 at 00:27 +0100, mouss wrote: > > My understanding was that OP asked about smtp time rejections. > obviously, this won't check received headers, nor junk from yahoo/gmail/... > milter-regex signature.asc Description: This is a digitally signed message part
Re: Freemail problem
/Very Ancient/ On Thu, 2010-06-10 at 18:40 +0200, Jeremy Fairbrass wrote: > Hi, I've noticed what seems to be unexpected behaviour with the Freemail > plugin, which I'm hoping someone can shed some light on. > > I'm using SpamAssassin 3.2.5, and the "FreeMail.pm" plugin v2.001 from > http://sa.hege.li, along with the rules from the 20_freemail.cf file at the > same location. > My second question is regarding the reference to > (financediamond[at]gmail.com) in the FREEMAIL_FROM results. That email > address does not appear *anywhere* in the entire message! Not in any of the > headers, nor in any part of the body. I've opened up the raw email file from > my mail server and searched the entire thing in a plain text editor, and > there is no reference anywhere to 'financediamond' at all. So why is the > FREEMAIL_FROM rule referring to that address? Is it a bug maybe? Could it > perhaps be crossing wires with another email which my SpamAssassin was > scanning at the same time, or something like that?? > > I am seeing this occasionally myself, including just now, except with 3.3.1 ( hence my search of the mailbox and found this, but only this post) somehow its mixing with addresses from separate emails altogether, this is postfix and SA is called from amavisd-new Was any suggestions given? Cheers signature.asc Description: This is a digitally signed message part
Re: Freemail problem
Mark, On Fri, 2011-02-18 at 15:20 +0100, Mark Martinec wrote: > Jeremy, Noel, > It's a bug in the FreeMail.pm plugin. It forgets to reset the rule description > text with every message, to the addresses listed in a rule description > just accumulate from one message to the next. I think this only affects > text in a report, the rules probably hit correctly. Thanks for this, strange how it does not happen all the time, but at least we know its mostly harmless. Cheers Noel signature.asc Description: This is a digitally signed message part
DKIM_SIGNED postive score
Hi, I note : DKIM_SIGNED=0.1 I've looked high and low and dont seem to be adding this locally, shouldn't it be a negative score of 0.1? Or better still, null, and only get a score if valid which is applied (DKIM_VALID=-0.1,), Seems the above only cancels this out and either way is not needed, or am I missing something? Cheers signature.asc Description: This is a digitally signed message part
Re: whitelist
Resurrecting an old thread but Lately I see a lot of false hits on FSL_RU_URL The only place in the email where .ru is, is in envelope-from , from, and the received headers, this is supposed to be from 72_active.cf:uriFSL_RU_URL /[^\/]+\.ru(?:$|\/|\?)/i (those also on the c-nsp list may also be seeing the same?) This only started recently. Cheers signature.asc Description: This is a digitally signed message part
Re: FSL_RU_URL Re: whitelist
On Thu, 2011-06-23 at 11:16 -0700, Adam Katz wrote: > On 06/22/2011 05:42 PM, Noel Butler wrote: > > Resurrecting an old thread but > > Lately I see a lot of false hits on FSL_RU_URL > > The only place in the email where .ru is, is in envelope-from , from, > > and the received headers, this is supposed to be > > from 72_active.cf:uriFSL_RU_URL /[^\/]+\.ru(?:$|\/|\?)/i > > > > (those also on the c-nsp list may also be seeing the same?) > > This only started recently. > > Full rule, originating from rulesrc/sandbox/maddoc/99_fsl_testing.cf > > uri FSL_RU_URL /[^\/]+\.ru(?:$|\/|\?)/i > tflags FSL_RU_URL nopublish > scoreFSL_RU_URL 0.01 > > I see several problems here. > > Chiefly, it's marked "nopublish" but is in some(?) copies of > 72_active.cf (not trunk, and the rule is completely absent from the > current 3.3 and 3.2 svn branches) ... is this out of sync? IIRC, we > fixed this problem a while ago, so perhaps Noel's system isn't properly > using sa-update, it hasn't propagated yet, or he's doing something fishy. > Hrmm sa-update reports no new updates, last touch date was march 25 Jun 24 10:21:24.410 [30018] dbg: dns: 1.3.3.updates.spamassassin.org => 1083704, parsed as 1083704 Jun 24 10:21:24.410 [30018] dbg: channel: current version is 1083704, new version is 1083704, skipping channel Nothing new to give me I've seen Warren's post about 3.3.2, so I'll be upgrading when our CPAN mirror offers it it. I've amended its score for time being to be very low so it cant wrongly influence. > As Ned answered, we need more information. Specifically, tell us about > your setup; what version (and package) of SpamAssassin are you using, > tell us about your sa-update configuration, any hacks, etc. > I use current versions from CPAN, I do not use distro supplied versions of any key daemon, even though slackware is pretty current in most of them, it often isn't build the way i need (eg: mysql etc) This occurs on each server, but i duplicate things so if one's wrong, the lot would be, I run it in a nightly cron as: /usr/bin/sa-update --channelfile /etc/mail/spamassassin/SAU-channel-list.txt (2 X gpg keys options removed) The /etc/mail/spamassassin/SAU-channel-list.txt file contains in this order: updates.spamassassin.org sought.rules.yerp.org 99_FVGT_Tripwire.cf.sare.sa-update.dostech.net Nothing too fancy as you see, although we do have a few local rules files, none of them have FSL in it. Whilst we on that, I do have a few from years gone by, do you know off hand if these are no longer needed postcards.cf rateware.cf 70_tt_drugs.cf 99_anonwhois.cf, the others I use give us hits, but its rare that those do. > Since FSL_RU_URL is so broad that it will match any link to any .ru > domain, we don't really need to see an example (unless you're confident > you have an example which lacks an actual .ru link ... this is a bug if > that's triggering on one of the headers you're mentioning). > That's what prompted me to ask, it is very broad. Cheers Noel signature.asc Description: This is a digitally signed message part
Re: How do I disable all spamhaus calls?
On Sat, 2011-08-13 at 09:18 -0400, Michael Scheidell wrote: > O > > CFO told me we could not pay for something that could be disabled > without notice. Especially when I told him what would happen if we > relied upon it, and it was disabled. (you rsync data goes blank... ) > > I can understand them not wanting someone to give away public access to > it, or to resell it, but I also would think some notice, or a phone call > to ask what is going on would be in order before cutting something this > critical off. > +1, for the ridiculous amount of money they demand, you'd certainly think they could afford the phone call. it's that very same policy that saw my previous CFO tell me " no way in hell", and this is a guy I can go to saying I need a new 50K server, and he'd say "sure, send me the ON" no questions asked for even what its for... signature.asc Description: This is a digitally signed message part
Re: Latest sa-update crashing sa-compile?
On Mon, 2011-08-15 at 16:34 -0400, Michael Scheidell wrote: > > I just did an sa-update and the problem didn't go away. > > > > I'm running trunk (3.4.0) updated a couple days ago. > > > not fixed yet. > > re2c: error: line 154, column 2: unterminated string constant (missing ") > command failed: exit 1 > mx1# > > > > I'm going to remove sought for now. > > > > Seeing that here still as well in 3.3.2 signature.asc Description: This is a digitally signed message part
Re: Supposed bounces
On 14/07/2022 04:24, Grant Taylor via users wrote: On 7/13/22 12:19 PM, @lbutlr wrote: So, a supposed bounce from also three years ago. And that bounce did not come from my mail server as I have never run qmail. No IP addresses, no Received headers, nothing that could possibly be used to figure out what is going on here. I think this is a courtesy message from the mailing list saying that a message that it tried to send to you was bounced. It provides a copy of (part of) the message for your convenience. Nothing about that implies that you sent the message that bounced. Instead it is extremely likely that you did not originate the message that bounced. ezmlm has been long brain dead, I particularly like its messages saying its reject message but never tells you the actual 5xx code. I aint about to go through 2019's logs to find out why either :) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Supposed bounces
On 14/07/2022 17:27, Benny Pedersen wrote: Noel Butler skrev den 2022-07-14 00:38: ezmlm has been long brain dead, I particularly like its messages saying its reject message but never tells you the actual 5xx code. I aint about to go through 2019's logs to find out why either :) Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 please stop doing this shit to maillists f@ck off -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Supposed bounces
On 19/07/2022 09:12, Grant Taylor via users wrote: Every version of what you describe that I've looked at has been the courtesy message. Which is a joke, because it does not, and qmails ezmlm has never included enough of the headers telling us _why_ we rejected it. But seriously folks, why the noise, its 3 years old (well mine was), get over it :) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Supposed bounces
On 19/07/2022 09:49, Grant Taylor via users wrote: At the very least they let you know that a message was rejected. I can then go look at my MTAs logs and deduce why message(s) were rejected with more authority than anything the MLM could tell me. Is that what you tell your customers? I'm damn sure it's not. But seriously folks, why the noise, its 3 years old (well mine was), get over it :) The age of what prompted the discussion doesn't negate the discussion. The discussion is OT, you've been around long enough, so has the other guy, to know how to query issues about the mlm, and none of it is bringing noise onto the list, which I too am now guilty of and shall be my last. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: subscribe to blacklist for domains
Why are you not blocking with blacklists at the border, ie: MTA. Given its 0 resources for your MTA, with anti spam checking on SA often using significant resources (depending on traffic/number of tests/rules etc), its best to stop it getting to SA in the first place. SA also has this by-default list of domains that it never checks, for along time I have disagreed with this, we are the ones to decide who gets whitelisted not SA, not some paid third party, the option clear_uridnsbl_skip_domain however prevents this, but then you have to locate and 0 all the general rulesets scores that are whitelists as well. On 13/08/2022 09:55, joe a wrote: I need to refresh my brain on using blacklists with SA, before looking more deeply into why this got through. Today a email slipped through with a very low score that was clearly phishy. A url in question, posing as another, hits no less that 6 blacklists. I was going to look at clamav that is in use here, as I had just been tuning that a bit and realized that that may be using a hammer to drive a screw. so to speak. Or are they passe these days? -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: subscribe to blacklist for domains
On 14/08/2022 02:38, Martin Gregorie wrote: 3) It would be rather trivial to return spam to sender with a suitable WTF, that has been a terrible idea since the 90s, given most spam is spoofed, the end result of this will be your mail server getting the poor reputation as source of backscatter and going into blacklists :) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: subscribe to blacklist for domains
On 14/08/2022 04:23, Bill Cole wrote: Not sure what you mean by that... There are a handful of rules that sidestep specific false positive cases because the hit being evaded isn't meaningful in specific cases. None of those are intended to 'whitelist' any domain, they exist to avoid incorrect hits. RCVD_IN_DNSWL* and some trusted rules, as two examples, in years gone by we've had obvious spam not binned because they were in those headers taking away the sticks harshness, so we disable them and all like them. I get it, small offices with no experienced IT on hand might find this annoying, but enterprises and ISP world are able to fine tune this, but we use a number of blacklists and complex milter-regex rules that stops 95% of the crud outright before hitting SA. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: subscribe to blacklist for domains
On 14/08/2022 22:37, Martin Gregorie wrote: On Sun, 2022-08-14 at 11:39 +1000, Noel Butler wrote: On 14/08/2022 02:38, Martin Gregorie wrote: 3) It would be rather trivial to return spam to sender with a suitable WTF, that has been a terrible idea since the 90s, given most spam is spoofed, the end result of this will be your mail server getting the poor reputation as source of backscatter and going into blacklists :) greed - I don't do that, but almost as long as I've been on this list there have been advocates of it. As I said, I thought about it, but the effort of writing a filter to determine what, if anything should be bounced or rejected, has never seemed worth the effort for such a low volume mail used as myself. Martin When people advocate for it, it goes to show the only thing they have ever been responsible for is their own home mail server with accounts for them and maybe a friend or two on it, never for anything commercial, you've been around a great many years Martin, so I'm glad you resist the temptation of the fools. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: subscribe to blacklist for domains
On 14/08/2022 23:15, David Bürgin wrote: To clarify: Backscatter is caused by 'rejecting' mail with a bounce message, after first accepting it. This is what was being suggested by some, I think everyone here knows what backscatter means, and what it is. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: subscribe to blacklist for domains
On 16/08/2022 01:33, Greg Troxel wrote: If you accept mail and then send it to /dev/null, then the recipient is unaware that it was sent, and the sender is unaware that it wasn't received, Exactly what happens to high scored spam, if its high is very obvious trash and the recipient wont want to know, and well who cares what those senders want to know :) So I'm a firm believer that at SMTP time, you need to pick one of 550 and you're done accept and then sort into ham mailboxes and spam mailboxes, with the idea that the user should be checking all of them or use both, 1 block the very obvious and non compliant; 95% 2 spam folder the "just triggering spam rules" - a problem with pop3 users (yes, speaking from an ISP world in Oceana they heavily outweigh number of imap users) so the labelled as spam stuff is mixed in their normal inbox ;0.1% 3 /dev/null the other obvious ; 0.0001% (ultra low becasue step 1 catches most) 4 inbox the rest As for spam folder checking not even I bother with mine except for once or twice a year -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: KAM channel disabling lookups?
On 12/10/2022 03:35, Henrik K wrote: On Tue, Oct 11, 2022 at 09:29:18AM +0300, Henrik K wrote: KAM channel (https://mcgrail.com/template/kam.cf_channel) users might want to check their rules.. KAM_deadweight2_sub.cf contains this: meta __RCVD_IN_SORBS 0 meta __RCVD_IN_ZEN 0 meta __RCVD_IN_MSPIKE_B 0 meta __RCVD_IN_MSPIKE_L 0 meta __RCVD_IN_DNSWL 0 Seems it's been disabling many active and useful DNSBL/WL lookups for a long time? Ah yeah, now I remember this bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7991 Apparently this isn't a "problem" in 3.4, as the channel can't even override anything from official rules.. so only affects recent 4.0.0/trunk users. or save SA doing extra work, and use the RBL's at MTA level - where they should be used and have been used for 25 years in the ISP world -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: welcomelist_auth and SPF
On 17/12/2022 08:35, Marc wrote: The sender's SPF record includes the sending IP (40.107.96.128) in the secureserver.net <http://secureserver.net> entry, and SPF_PASS is hit. Without even checking anything I can already remember that this secureserver.net is shit. I have blocked whole ranges of them, they send spam, try passwords etc. I have the impression that there is nothing secure about secureserver and everything seems to be hacked there. s/secureserver/google/ s/secureserver/amazon/ s /secureserver/microsoft/ s /secureserver/ ... / I often have gmail accounts hit our honeypots, to the point that I now deliberately take a week or more to clear the google smtp of the day off the list, each time, I take longer and longer to remove - just like other providers and I currently have a large chunk of google/amazon/MS/linode/D.O/... cloud ranges blocked. My point is, they are all the same and if someone wishes to whitelist them, that's the risk they take, they are answerable to their users, not to you, me or anyone else. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: KAM FP
Pains me to agree with Benny, but the rules should be split out... On 20/01/2023 09:07, Benny Pedersen wrote: * 5.0 KAM_SOMETLD_ARE_BAD_TLD .buzz, .cam, .club, .link, .live, minor annoyances, score closer to 1 .shop, .stream, .top, abused, score closer to 2 more appropriate xyz .online massively abused, 5 is too low, but most ISP's and enterprises MTA block those two anyway. YMMV (but unlikely on the last two me thinks)... this is based on Australasia, can't speak for what is seen in the EU or US -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: [EXTERNAL] Re: Mailing list is being Spam Filtered by O-365
That is not a freeradius.org server that I can see, completely different network even... /var/mail/corp/n/o/e/noel.butler/Maildir/.Lists.FreeRadius/cur# grep "63.88.93.251" * | wc -l 0 Messages in folder 28047 CC'd F/R ML since you also posting this issue over there On 20/04/2023 21:47, White, Daniel E. (GSFC-770.0)[AEGIS] via users wrote: How about this: Received: from BL0GCC02FT019.eop-gcc02.prod.protection.outlook.com (2a01:111:f400:7d05::201) by CYXPR09CA0020.outlook.office365.com (2603:10b6:930:d4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.25 via Frontend Transport; Thu, 20 Apr 2023 11:27:54 + Authentication-Results: spf=fail (sender IP is 63.88.93.251) <- smtp.mailfrom=lists.freeradius.org; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=lists.freeradius.org;compauth=none reason=452 Received-SPF: Fail (protection.outlook.com: domain of lists.freeradius.org <- does not designate 63.88.93.251 as permitted sender) receiver=protection.outlook.com; client-ip=63.88.93.251; helo=vsmtpx-e100-01.localdomain; -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Mailing list is being Spam Filtered by O-365
Oh, same IP again in this message, you are forwarding your mail via verizon business aren't you, no, there is nothing wrong with SA, FR lists nor Harrys setup when you forward, you risk breakage, only you can deal with this. On 20/04/2023 22:08, White, Daniel E. (GSFC-770.0)[AEGIS] via users wrote: Sorrry. Mixing up lists Received: from BL0GCC02FT027.eop-gcc02.prod.protection.outlook.com (2a01:111:f400:7d05::201) by CY4PR09CA0046.outlook.office365.com (2603:10b6:903:c0::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.25 via Frontend Transport; Thu, 20 Apr 2023 11:50:41 + Authentication-Results: spf=fail (sender IP is 63.88.93.251) ß smtp.mailfrom=thelounge.net; dkim=none (message not signed) ß header.d=none;dmarc=none action=none header.from=thelounge.net;compauth=fail reason=001 Received-SPF: Fail (protection.outlook.com: domain of thelounge.net does not designate 63.88.93.251 as permitted sender) receiver=protection.outlook.com; client-ip=63.88.93.251; helo=vsmtpx-e100-03.localdomain; __ Daniel E. White daniel.e.wh...@nasa.gov NASCOM Linux Engineer NASA Goddard Space Flight Center Office: (301) 286-6919 Mobile: (240) 513-5290 From: Reindl Harald Organization: the lounge interactive design Date: Thursday, April 20, 2023 at 07:50 To: Daniel White , "users@spamassassin.apache.org" Subject: Re: [EXTERNAL] Re: Mailing list is being Spam Filtered by O-365 CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Am 20.04.23 um 13:47 schrieb White, Daniel E. (GSFC-770.0)[AEGIS] via users: How about this: how about realize that "@lists.freeradius.org" has nothing to do with "@spamassassin.apache.org"? Received: from BL0GCC02FT019.eop-gcc02.prod.protection.outlook.com (2a01:111:f400:7d05::201) by CYXPR09CA0020.outlook.office365.com (2603:10b6:930:d4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.25 via Frontend Transport; Thu, 20 Apr 2023 11:27:54 + Authentication-Results: spf=fail (sender IP is 63.88.93.251) <- smtp.mailfrom=lists.freeradius.org; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=lists.freeradius.org;compauth=none reason=452 Received-SPF: Fail (protection.outlook.com: domain of lists.freeradius.org <- does not designate 63.88.93.251 as permitted sender) receiver=protection.outlook.com; client-ip=63.88.93.251; helo=vsmtpx-e100-01.localdomain; From: Reindl Harald Organization: the lounge interactive design Date: Thursday, April 20, 2023 at 07:36 Subject: [EXTERNAL] Re: Mailing list is being Spam Filtered by O-365 Am 20.04.23 um 13:20 schrieb White, Daniel E. (GSFC-770.0)[AEGIS] via users: Is there any chance that SPF and DKIM records could be added to appear in the headers ? what makes you believe that SPF is part of mail-headers? dig +short TXT spamassassin.apache.org; "spf2.0/pra ?all" "v=spf1 include:_spf.apache.org -all" Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=3.227.148.255; helo=mxout1-ec2-va.apache.org -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: new zip tld
On 19/05/2023 20:54, Benny Pedersen wrote: https://news.netcraft.com/archives/2023/05/17/phishing-attacks-already-using-the-zip-tld.html good or bad, i really dont know https://twitter.com/hnasr/status/1658853944037351424 -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
0 score not voiding rule
USER_IN_WELCOMELIST 0 apparently does not disable the rule (like 0 disables all the others), is that a way of forcing your world view upon the rest of the world Kevin? it is still scoring negative values on messages despite being set some time ago, and surviving "new kernel" server restarts -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: 0 score not voiding rule
On 28/05/2023 02:53, John Hardin wrote: On Sat, 27 May 2023, Noel Butler wrote: USER_IN_WELCOMELIST 0 apparently does not disable the rule (like 0 disables all the others), it is still scoring negative values on messages despite being set some time ago, and surviving "new kernel" server restarts Did you also add: USER_IN_WHITELIST 0 They are synonyms, might need to kill both explicitly. Thanks John, will check that out this morning. I thought this welcome crap wasnt being applied until next release... I guess Kevin that changed quickly, I might have missed the change as I admit to having little time for most lists these days, family life too hectic :) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: 0 score not voiding rule
AS usual I still dont get whatever you're going on about benny, but v4 was where these changes were to be, yes, BUT none of our servers are on v4 ls /var/lib/spamassassin/ 3.004006/ compiled/ On 28/05/2023 00:06, an unmedicated Benny Pedersen trolled: -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: 0 score not voiding rule
On 28/05/2023 12:02, Thomas Cameron wrote: On 5/27/23 17:21, Noel Butler wrote: apparently does not disable the rule (like 0 disables all the others), is that a way of forcing your world view upon the rest of the world Kevin? I thought this welcome crap wasnt being applied until next release... I guess Kevin that changed quickly, I might have missed the change as I admit to having little time for most lists these days, family life too hectic :) Pretty bold to be a jerk to a guy you're asking for help from. Be nice, Noel. It's not that hard. I don't know why you've got a burr under your saddle, but it's definitely not making a good impression to be shitty on a public mailing list while you're asking for help. *yaaawn* I'm an early usenetter, I never wrapped idiocy up in cotton wool back then, I'm not about to start now. plonk? oh no what will I do... roflmfao -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: authres do not parse sender-id
On 05/06/2023 03:38, Matus UHLAR - fantomas wrote: is sender-id still not depricated ? it's status: historic. It's also patended and since it's broken by design, there's no reason to support or use it. Supporting it used to tip you over the "your-not-spam" line with MS's cleanfeed, no idea if it still works that way as I lost my MS contact when she left for greener pastures. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Sudden surge in spam appearing to come from my email address
On 16/07/2023 04:44, Cathryn Mataga wrote: Someone has figured a way to use gmail to spam from their servers, looks like to me. huh? They have been doing this for YEARS, google don't care because they get to scan (inspect) all the mail, even in transit, that's not "tinfoil hat" rubbish either since they long admit it. it's why anyone who whitelists gmail is a fool (much like those who use gmail in the first place), we in fact add a positive score for all google/gmail connections -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Sudden surge in spam appearing to come from my email address
On 17/07/2023 20:00, Benny Pedersen wrote: Noel Butler skrev den 2023-07-16 02:05: it's why anyone who whitelists gmail is a fool (much like those who use gmail in the first place), we in fact add a positive score for all google/gmail connections you still have bigger signature then google/gmail on public maillists and I'm supposed to care because why, did you forget to take your meds again Benny... -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Ensuring SPF/DKIM for @gmail.com
On 26/07/2023 17:34, Benny Pedersen wrote: milters should not be spam scanners, spamassassin is better SA is perl, perl is faster and better resource nice than python garbage, but perl is still slow compared to C, that is why milters will win out everytime. milter-regex is also light and super speedy, it stops a lot of trash before postfix even accepts the message to give to SA Frankly google is just trash anyway, so anything that blocks gmail/google spam is a great idea. (have they stopped google groups from backscatter yet, probably not, they are too busy fscking over youtube) -- Regards, Noel Butler - Ensuring my "long sig" is even longer, just for Benny This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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. This I care not about mailing lists, although this is only a list/newsletter account its not my personal account Its one of my older formal but not personal addresses nbot really used in that lght now. thinking of other stuff to put in to annoy Benny but damn running outof time, time to go home its 5.50 pm
Re: Ensuring SPF/DKIM for @gmail.com
On 27/07/2023 05:09, Matija Nalis wrote: Any SPF, no matter how correctly configured, will lead to false positives in some cases (e.g. encoutering mailing list B.S. mailing lists have been smart enough for over 20 years to rewrite sender and not appear as a basic forwarder - which are you are correct, however there are forwarding abilities to rewrite sender which avoids this, its been 15 years or more since I've used procmail which by default did not. If you are going to dry-reach to support an argument, please use modern facts and not 1990's. I was a *very* early adopter of SPF back in late 90's and have had zero issues in 20 years in using SPF (as expected as an early adopter, teething issues as with all software needed fine tuning in very early days) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Ensuring SPF/DKIM for @gmail.com
On 27/07/2023 10:20, Matija Nalis wrote: mailing lists have been smart enough for over 20 years to rewrite sender and not appear as a basic forwarder - which are you are correct, however there are forwarding abilities to rewrite sender which avoids this, its been 15 years or more since I've used procmail which by default did not. I personally know several people who still use procmail today, sooo... Your assumption seems to be that EVERYBODY upgrades on regular (yearly-or-so?) cycles, and updates their configs to latest recommended practices at the same time. This is ideal but reality is far different, that said, most would not be using anything from 1990's, if they are, they are have far bigger issues than SPF. That at least I can attest is not always the case (I still see systems with custom sendmail.cf which nobody dares to touch, and with a good reason!) As above. But I won't agree that "it does not exist", nor would I agree that it doesn't matter (if it didn't matter to them, people wouldn't be asking me to troubleshoot it, and yet they do) It "does, not matter", you can't help those who wont help themselves, I'm sure we all remember this back in days when banks and governments wouldt run compliant DNS, they all expected us to whitelist them, when they realised that was not going to happen en masse, they got their act together and fixed their stuff, now, at least in this country, they woke up and realised the benefits so much so, the govt here is a strong proponent of DMARC and mandates all federal govt depts to use it (though I've discovered some that dont) Good for you. But that is anecdotal - you are certainly not participating in every mailing list in existence, I'm on 117 mailing lists - not that I have time these days to read much of it, family life is more important, in past couple weeks I just found a few hours to peruse some :) So, still in 2023, I have to deal with SPF (and DKIM) failing due to such forwarders/ML (as well as misconfigurations, of course) DKIM is a total failure with mailing lists, but DKIM - unlike SPF in a typical setup, is not an out-right reject at MTA level. Also, 1990s? Weren't first SPF-alike ideas drafted first time in early-mid 2000s, and SPF itself not published as *proposed* IETF standard until 2014? That was less than a decade ago, barely yesterday :) No, SPF pre dates that, 1998 or there abouts if my ageing memory serves me correct, 2014 might have been the SPF RR type, which certain cretins from the debian world fought long hard against as their dist versions of bind didnt understand it it was that old (heaven forbid debian users ran modern software - I hope thats changed since but somehow I suspect not...) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Ensuring SPF/DKIM for @gmail.com
On 27/07/2023 13:43, Bill Cole wrote: No, SPF pre dates that, 1998 or there abouts if my ageing memory serves me It's failing... :) SPF originated with an idea of Gordon Fecyk, first written up AFTER he left MAPS in 2001. First ID calling it SPF would have been 2003 or so. A brief refresher from https://dmarcian.com/history-of-spf/ I'm remembering tiny bits here and there, pfft I'm nearing retirement, so maybe that should be sooner rather than latter :) But 20 years is a long time either way, and the base of my comments stand, if you're using an OS or daemon that's that old (or even 10 years ago), you STILL have much bigger problems than someone rejecting you on SPF :) The oldest mail server log I can find is from mx-in-08 sadly even that one is only from 2005 but confirms we were using it then, quite a bit longer than 2014 :P -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Ensuring SPF/DKIM for @gmail.com
On 27/07/2023 17:48, Marc wrote: The oldest mail server log I can find is from mx-in-08 sadly even that one is only from 2005 but confirms we were using it then, quite a bit longer than 2014 :P Why retire? To go fishing or so? I think GDPR even prohibits keeping very old log files, if there is no specific reason for that. Nah, I could never catch anything more than a cold, but I do like camping though, peaceful bliss, no server fans droning, no phones ringing, no sitting in traffic... even better that most remote spots are RF noise free for amateur radio activities whilst other half sleeps her head off ;) As for GDPR, it doesn't affect us, we don't provide services outside our own country, also our government, like other "five eyes" nations, are perverted control freaks and tend to view all citizens as criminals and enemies of the state, so they would be pleased at that duration, we have a meta-data retention law that says we must keep CDR's and mail and web server logs for "minimum" of 2 years, funny though, they dont want us to keep usenet logs, because the vile scum of the earth and warez pups have never heard of usenet have they LOL -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Ensuring SPF/DKIM for @gmail.com
On 27/07/2023 18:11, Marc wrote: I am always using -all. I honestly can't think of a good argument to use anything else. I agree. It's my belief that ~all is only useful for a "production entry test phase", once your happy, move to -all Like DMARC's p=none it's a "getting it going" method that's for you to get shit right, then move to p=quarantine, although from memory some European countries (Germany?) require or use to require you to either accept the message and deliver it, or outright block it with a reject message, I'd like to think they've changed that though. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: DMARC and SA4
On 27/09/2023 12:31, Bill Cole wrote: Quarantine is a silly concept. Users hate it in practice. Citation please? My experiences over the many years differ SpamAssassin does not implement any form of quarantine. This is not because it's a bad idea, but because SA doesn't implement ANY handling of delivery and storage. Nor should it :) -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
STY_INVIS_DIRECT
72_active.cf/STY_INVIS_DIRECT Anyone else seeing this go haywire? It's triggering on legit emails everywhere, even from paypal, for past few days by looks of helpdesk, and my own paypal email this morning, 2.5 score is pushing a lot of Email into "Junk folders", for now I'ma change that score to 0.25 -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: Anybody else getting bombarded with "I RECORDED YOU" spam?
On 11/11/2023 22:37, Mike Bostock via users wrote: There is a way to whitelist domains with no RDNS but so far I haven't found a way to do this in the .mc file. Thanks again /etc/mail/access Connect:foo OK -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message 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.
Re: ATT RBL f---wits
~$ host 24.116.100.90 ;; connection timed out; no servers could be reached Seems like AT&T *ARE* doing the correct thing and it is *YOU* with the problem. before you start calling others f'wits do better investigation, a dig trace indicates root servers dont know you. On 28/11/2023 07:31, Philip Prindeville wrote: We're being blacklisted by att.net with the following message: (reason: 550 5.7.1 Connections not accepted from servers without a valid sender domain.flph840 Fix reverse DNS for 24.116.100.90) I don't know what the hell is up with these pinheads: philipp@ubuntu22:~$ dig -tmx redfish-solutions.com. @8.8.8.8 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> -tmx redfish-solutions.com. @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58379 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;;~$ host 24.116.100.90 ;; connection timed out; no servers could be reached QUESTION SECTION: ;redfish-solutions.com. IN MX ;; ANSWER SECTION: redfish-solutions.com. 21600 IN MX 10 mail.redfish-solutions.com. ;; Query time: 48 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sun Nov 19 15:08:29 MST 2023 ;; MSG SIZE rcvd: 71 philipp@ubuntu22:~$ dig -ta mail.redfish-solutions.com. @8.8.8.8 ; <~$ host 24.116.100.90 ;; connection timed out; no servers could be reached <>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> -ta mail.redfish-solutions.com. @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19570 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mail.redfish-solutions.com. IN A ;; ANSWER SECTION: mail.redfish-solutions.com. 21600 IN A 24.116.100.90 ;; Qu~$ host 24.116.100.90 ;; connection timed out; no servers could be reached ery time: 72 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sun Nov 19 15:08:39 MST 2023 ;; MSG SIZE rcvd: 71 philipp@ubuntu22:~$ dig -x 24.116.100.90 @8.8.8.8 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> -x 24.116.100.90 @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2371 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;90.100.116.24.in-addr.arpa. IN PTR ;; ANSWER SECTION: 90.100.116.24.in-addr.arpa. 21600 IN PTR mail.redfish-solutions.com. ;; Query time: 68 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sun Nov 19 15:08:55 MST 2023 ;; MSG SIZE rcvd: 95 philipp@ubuntu22:~$ So that's not the problem. You're supposed to be able to get the blacklisting fixed if you email abuse_...@abuse-att.net <mailto:abuse_...@abuse-att.net> but I've emailed them from 3 different addresses and have yet to get a response much less a resolution. Has anyone else had to deal with this bullocks and gotten it resolved? Thanks -- Regards, Noel Butler
Re: ATT RBL f---wits
On 28/11/2023 08:59, Noel Butler wrote: ~$ host 24.116.100.90 ;; connection timed out; no servers could be reached Seems like AT&T *ARE* doing the correct thing and it is *YOU* with the problem. before you start calling others f'wits do better investigation, a dig trace indicates root servers dont know you. Seems your IP provider is the onle with problems, now I get an answer of sorts ~$ dig +trace -x 24.116.100.90 < snip > 116.24.in-addr.arpa. 86400 IN NS ns2.cableone.net. 116.24.in-addr.arpa. 86400 IN NS ns1.cableone.net. 116.24.in-addr.arpa. 10800 IN NSEC 117.24.in-addr.arpa. NS RRSIG NSEC 116.24.in-addr.arpa. 10800 IN RRSIG NSEC 8 4 10800 20231211213247 20231127203247 6558 24.in-addr.arpa. ChfIccQU9mphSoPwTZf6Og2pumL3BRTQBGm7ZyFb5R8ycVL/jyXD94O8 XOLL48wgXFQPuW4bfoSlmB/nNJ4tfb1Vyeb3x5MmVQTL74tdotoGfFYS 2+gjyFWYkWAtkzOAmC7Eeva7hotpQ9Qa3LbkFtfznKBFdPAHHQ1vXs0K Shg= ;; Received 366 bytes from 199.180.180.63#53(r.arin.net) in 194 ms ;; connection timed out; no servers could be reached On 28/11/2023 07:31, Philip Prindeville wrote: We're being blacklisted by att.net with the following message: (reason: 550 5.7.1 Connections not accepted from servers without a valid sender domain.flph840 Fix reverse DNS for 24.116.100.90) I don't know what the hell is up with these pinheads: -- Regards, Noel Butler
Re: ATT RBL f---wits
On 29/11/2023 00:51, Tracy Greggs via users wrote: Cableone is SOA on this zone, so they are the issue. You can ask them to create a PTR for your static IP and hope for the best. Most I have dealt with will do it as long as it's a commercial account. As I pointed out - but failed to copy/paste a couple extra lines - cableone have issues, earlier they were reporting SERVFAIL then it was unreachables. The fact OP showed google knowing his PTR. says he should not have to have them add it manually, they need to fix what they already have - or they need to pay their bill :) It's also why we dont accept reports here that " oh google says its there" because google have a history of not honouring TTL's, and it always pays to use a DNS server that you don't think would have your zone cached, to get a fresh perspective. -- Regards, Noel Butler
Re: [EXTERNAL] Re: Catch a rejected message ?
On 02/12/2023 05:16, Benny Pedersen wrote: White, Daniel E. (GSFC-770.0)[AEGIS] via users skrev den 2023-12-01 16:35: why do you reply to a member that can't answer on maillist ? From: Reindl "Toxic Troll" Harald Because that moderated troll has a long known habit on most of the lists he's moderated on (which is pretty much everyone) of setting reply-to-list, and those who don't know better, don't bother to check where they're replying to. Which is kinda worrysome since the same people are supposed to be mail administrators. -- Regards, Noel Butler
Re: OT: Trigger words in email addresses?
On 08/04/2024 11:40, Jerry Malcolm wrote: Now here's my question (at least one of them)... I send the validation email from DoNotReply So... recommendations, please... should I change donotre...@.com to something else, and if so, what is Typically, noreply@... is used Have you tried using that sender from a non AWS host, even for just a test? My bet is, it's scoring higher because of AWS, who are abused often by spammers and scammers. server and using AWS's SES SMTP server for outbound. The and therein probably lies the answer. -- Regards, Noel Butler
Re: WARNING: Microsoft has earned removal from SA default welcomelist
On 13/04/2024 03:20, Bill Cole wrote: In my opinion, this is an indication that the default welcomelist entries in the official I'm good with that, so long as likes of google are not in any whitelist either. I haven't been following all the anti spam stuff as much as I used to (I have people to do that for me so I can enjoy more of life) in past few years, but I've never believed the big providers should ever have been whitelisted. I've used clear uridnsbl skip domain for donkies years (I think that's the option that removes the dnsbl whitelistings going off memory) but perhaps there should also be a similar command (if not already exist?) that clears and disables /all/ whitelisting in rules as well, yes I know in the past the recommended method was writing a gazillion entries in local.cf zeroing out there scores, but isn't that kind of stupid in 2024. Trust must be earned, not implied (or bought), as Joanne points out, "my spam is your ham and vice versa" -- Regards, Noel Butler
Re: WARNING: Microsoft has earned removal from SA default welcomelist
On 13/04/2024 19:27, Marc wrote: All nice and well, but a bit decades to late. There should never have been such default whitelist. Companies should take care not be on blacklists, and should maintain some Absolutely, no arguments there! After all spf -all exists already for a long time. So why are google/microsoft/yahoo etc still not using it? Why don't Mostly because all the google spam would pass spf/dkim/dmarc anyway, at least tehy tend to learn you more as ham than spam if you send to them with spf. they separate free/spam clients on different infrastructure. Google do IIRC, Microsoft don't, it's why you wont find many of our sites in bing, because they use their own search bots in IP ranges shared with f'wit script kiddies, and I issued a directive no whitelisting for MS search bots - not until they stick em all in one subnet that does not, never has and never will have customers in it. Now these companies are big enough to abuse the market and force everyone to customize just for them. If you would sadly, thats true, they think they are too big to block, but they have all at some time found I don't work that way, nobody, is too big to block, and its a shame that likes of spamhaus and spamcop operate that way too, essentially shrugging their shoulders and going "oh well" It is just crazy that on the internet you are expected to clean up someone else's mess. Ahmen to that. -- Regards, Noel Butler
Re: spamassassin with gmail
On 16/04/2024 08:24, Michael Grant via users wrote: I am not at all advocating people use gmail. Something like 68% of the planet already uses it and few people like I really wonder about that, or did they pull a trump... I ran this June last year, the results are somewhat surprising, of course YMMV depending upon you're countries politics or what your ISP is like I guess. https://blog.ausics.net/archives/147-How-do-you-use-Email.html Michael Grant -- Regards, Noel Butler
Re: Whitelist rules should never pass on SPF fail
On 09/05/2024 05:57, Jarland Donnell wrote: That's easy though at least. Set the DNSWL rule to 0. I appreciate their effort but it's simply not an accurate way to determine the value of an email in 2024. It's never been the deciding factor between whether or not an email was spam, in any email I've audited in the last decade. This! Trust must be earned, not assumed (or bought) -- Regards, Noel Butler
Re: Whitelist rules should never pass on SPF fail
On 09/05/2024 22:47, Bill Cole wrote: On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200) Benny Pedersen is rumored to have said: Bill Cole skrev den 2024-05-09 14:22: In fact, I can't think of any whitelist test that should pass if SPF fails. If you operate on the theory that a SPF failure is always a sign of spam, you can make your SpamAssassin always trust SPF failures absolutely. I would not recommend that. Some people screw up their SPF records. Other people forward mail transparently, which reliably breaks SPF. SPF is broken *by design* as a spam control tool AND as a mail authentication tool. We knew this 20 years ago, but it remains a useful tool if you work with its limits rather than assuming that they do not exist. spf domain owner asked for hardfails, so why not score spf_fail as 100 ? :) I believe that has been covered in extreme detail and redundancy here and in other email-related fora MANY times over the past 20 years. Domain owners do not KNOW all the paths their mail follows, even when they think that they do. Users frequently find ways to break SPF without doing anything wrong. It's not often I agree with what Benny says, but this is one of them. So what? domain owners state hard fail it SHOULD be hard failed, irrespective of if YOU think you know better than THEM or not, if we hardfail we accept the risks that come with it. This is why SPF should always be handled separately by a milter, so a hard fail wont make it to spamassassin or others who think they can ignore a domain owners wishes. -- Regards, Noel Butler
Re: Whitelist rules should never pass on SPF fail
On 11/05/2024 03:40, Bill Cole wrote: So what? domain owners state hard fail it SHOULD be hard failed, irrespective of if YOU think you know better than THEM or not, if we hardfail we accept the risks that come with it. In practice, there is a prioritizing of whose wishes I prioritize on the receiving systems I work with. If my customer wants to receive the mail and the individual generating the mail is not generating that desire fraudulently, I don't care much about what the domain owner says. I hope you have an indemnity clause in your contracts (or written statement from them) to legally protect you, and your professional indemnity insurance (or your countries version of it) is current... I do not work for the domain owners of the world and I am not obligated to enforce their usage rules on their users. Obligated no, its your network, your rules, but honouring them is the correct "good netizen" thing to do. I'm sure the crime gangs and spammers reading this list greatly appreciate you telling them they got better chances with you then most :P Obviously I take their input seriously when trying to detect fraud but I've seen too many cases of "-all" being used with incomplete or obsolete lists of "permitted" hosts to accept that they know all of the places their mail gets generated. The idea of using -all is not just configuring it and forgetting it, it's part of the accepted risk that if you change something, you change your SPF statements too, if they forget, the complaints of blocked mail should prompt them to fix it, or if they are just flat out too damn lazy, then they get what they deserve. Adherence has improved out of sight in past 5 to 10 years, and I've seen no problems caused by SPF, I can't remember the last time we had one. I've also given up all hope of getting the few places that are still doing transparent forwarding to adopt SRS or any other mechanisms to avoid SPF breakage to ever change. I guess the traffic with them is low, if it was high, blocking would likely get them off their buts. -- Regards, Noel Butler
SA treats percentage spaces wording as uri
This morning one of our ent_domains DMARC weekly report from a third party was listed as spam by SA which took the wording Not_percent-twenty_Resolved and passed it off to URI checks adding dot.com to it when there is no dot com after it, and a raw message search of that message in less in console confirms it. Problem with the code that scans the content for things like URI's? It shouldn't be assuming there's a TLD after it. -- Regards, Noel Butler
Re: Multiple REFUSED logs with sorbs.net ?
On 18/05/2024 08:14, J Doe wrote: Hello, I make use of SpamAssassin 4.0.0 on a low volume e-mail server. I also run my own validating resolver with Bind 9.18.27 on the e-mail server. The only piece of software I have in my e-mail stack that uses SORBS is SpamAssassin. I have noticed in my resolver logs multiple entries where a query of SORBS results in REFUSED results. Here is an example entry: 10-May-2024 05:34:39.024 lame-servers: info: REFUSED unexpected RCODE resolving 'rbldns10.sorbs.net/A/IN': 108.59.172.201#53 While some queries succeed and SpamAssassin appears to be able to use SORBS, there are always *multiple* REFUSED results only for sorbs.net. Am I exceeding the number of free queries that SORBS allows ? If so, do I need to register with SORBS (similar to how SpamHaus requires registration to use their DQS service) ? If so, how do I update my SA configuration ? Thanks, - J SORBS has been ultra sensitive like that for a few years now, it allows lookups, then it doesn't, seconds later it does, I suspect an ill configured DoS protection mechanism that's overly paranoid, but good luck getting anyone their to listen. -- Regards, Noel Butler
Re: kam fails if askdns is disabled
On 26/05/2024 01:20, Antony Stone wrote: On Saturday 25 May 2024 at 16:57:21, Benny Pedersen wrote: Antony Stone skrev den 2024-05-25 16:52: Is this a reply to something? something ?, try disable askdns plugin, then do spamassassin --lint succes ? hopefully kam know why there should not be lint errors if just check plugin is enabled, where all other plugins is disabled I apologise for not having worked that out from "+1". Antony. Shame on you for not turning on ESP ;) When Benny is off his meds, he's like the newbies who lodge support tickets saying "mail doesnt work" not I cant get my mail because of error fooXXX or cant send mail because im an idiot and cant read that we dont relay out on port 25, or im trying to relay using my old isps mail server... *sigh* but you get used to ignoring Benny's unintelligible shit. -- Regards, Noel Butler
Re: DKIM ... KAPUT
On 13/06/2024 08:59, Rupert Gallagher wrote: Yesterday I disabled DKIM as a spam indicator, because I got tired of adding exceptions. Non-compliant relays should fail hard, but they do not. This is a tragedy. I have NFI why you wasted your time telling us this DKIM only proves it was sent from domain X, it has ZERO to do with "is or is not" spam. So again, venting your annoyance at your misunderstanding of DKIM with us, is pointless. -- Regards, Noel Butler
Re: Where are your test definitions?
On 15/06/2024 01:04, Thomas Barth via users wrote: Am 2024-06-14 16:44, schrieb Reindl Harald (privat): with RDNS_NONE nobody on this planet should accept mails from that machine and the admin has to be fired, the message should be jejected at SMTP level long before spamassassin And you would have been dismissed because of your pathological fascist thought structure ;-) Not if he worked for me, it's smtp 101 not only enforce PTRs, but enforce matching A/ -> PTR and back again, so they need fix their mail server DNS, the bad relay country, not a lot they can do about that to that sender. That said, Harry would never work for me because as you pointed out he's pathological, it's why he replies privately, he is perm moderated on this and most other lists, please do not reply to him via the list, hehas a habit of setting the reply-to, to the list, please check and remove it, feel free to tell him what you think of him directly, the rest of us already have. -- Regards, Noel Butler
URIDNSBL check return code
Hi,
Is there a way to get the return code in the generated reports?
eg:
uridnssub ALT_URI bl.foo A 127.0.0.2-127.0.0.11
body ALT_URI eval:check_uridnsbl('ALT_URI')
describe ALT_URI URL's domain A record listed in bl.foo ($RETRUN_CODE)
score ALT_URI 3.0
tflagsALT_URI net a
so if the check matched on 127.0.0.6, desc would be
describe ALT_URI URL's domain A record listed in bl.foo (127.0.0.6)
Thanks for any pointers
Re: URIDNSBL check return code
Hi Kevin,
Thanks, will try this out after lunch and get back to you.
Cheers
Noel
On 26/07/2014 03:26, Kevin A. McGrail wrote:
> On 7/24/2014 9:42 PM, Noel Butler wrote:
>
>> Hi, Is there a way to get the return code in the generated reports? eg:
>> uridnssub ALT_URI bl.foo A 127.0.0.2-127.0.0.11 body ALT_URI
>> eval:check_uridnsbl('ALT_URI') describe ALT_URI URL's domain A record listed
>> in bl.foo ($RETRUN_CODE) score ALT_URI 3.0 tflags ALT_URI net a so if the
>> check matched on 127.0.0.6, desc would be describe ALT_URI URL's domain A
>> record listed in bl.foo (127.0.0.6) Thanks for any pointers
>
> Nothing currently in the code Looks like you would have to modify URIDNSBL.pm
> to add that info in the sub got_dnsbl_hit to add to the test_log data
>
> From looking, $str contains the return data so likely need to look through
> $uris and add $str to this line:
>
> $pms->test_log ("URIs: $uris");
>
> Let us know if it works and perhaps it's worth adding to the codebase.
>
> Regards,
> KAM
Re: URIDNSBL check return code
On 26/07/2014 03:32, Axb wrote:
> On 07/25/2014 07:26 PM, Kevin A. McGrail wrote:
> On 7/24/2014 9:42 PM, Noel Butler wrote: Hi, Is there a way to get the return
> code in the generated reports? eg: uridnssub ALT_URI bl.foo A
> 127.0.0.2-127.0.0.11 body ALT_URI eval:check_uridnsbl('ALT_URI') describe
> ALT_URI URL's domain A record listed in bl.foo ($RETRUN_CODE) score ALT_URI
> 3.0 tflags ALT_URI net a so if the check matched on 127.0.0.6, desc would be
> describe ALT_URI URL's domain A record listed in bl.foo (127.0.0.6) Thanks
> for any pointers Nothing currently in the code Looks like you would have to
> modify URIDNSBL.pm to add that info in the sub got_dnsbl_hit to add to the
> test_log data From looking, $str contains the return data so likely need to
> look through $uris and add $str to this line: $pms->test_log ("URIs: $uris");
> Let us know if it works and perhaps it's worth adding to the codebase.
what's the advantage of such a response method?
The idea of separate return codes is to use different rules/scores and
different rule descriptions which describe the type of listing
As you see, we use .2-.11 for this rule, the RC is only for internal use
here so support can identtify which list, (we have two others that use
singular codes that are rule specific) so are you suggesting that rather
than that one rule, we have ten rules doing exactly the same thing?
That's not very efficient :)
Re: URIDNSBL check return code
On 26/07/2014 03:26, Kevin A. McGrail wrote:
> On 7/24/2014 9:42 PM, Noel Butler wrote:
>
>> Hi, Is there a way to get the return code in the generated reports? eg:
>> uridnssub ALT_URI bl.foo A 127.0.0.2-127.0.0.11 body ALT_URI
>> eval:check_uridnsbl('ALT_URI') describe ALT_URI URL's domain A record listed
>> in bl.foo ($RETRUN_CODE) score ALT_URI 3.0 tflags ALT_URI net a so if the
>> check matched on 127.0.0.6, desc would be describe ALT_URI URL's domain A
>> record listed in bl.foo (127.0.0.6) Thanks for any pointers
>
> Nothing currently in the code Looks like you would have to modify URIDNSBL.pm
> to add that info in the sub got_dnsbl_hit to add to the test_log data
>
> From looking, $str contains the return data so likely need to look through
> $uris and add $str to this line:
>
> $pms->test_log ("URIs: $uris");
>
> Let us know if it works and perhaps it's worth adding to the codebase.
>
> Regards,
> KAM
Works a treat!
Thanks, does exactly what we need.
Re: URIDNSBL check return code
IOn 30/07/2014 00:30, Kevin A. McGrail wrote:
> Nothing currently in the code Looks like you would have to modify URIDNSBL.pm
> to add that info in the sub got_dnsbl_hit to add to the test_log data
>
>> From looking, $str contains the return data so likely need to look through
>> $uris and add $str to this line:
>
> $pms->test_log ("URIs: $uris");
>
> Let us know if it works and perhaps it's worth adding to the codebase.
>
> Regards,
> KAM
>
> Works a treat!
>
> Thanks, does exactly what we need.
OK, I'm assuming this is not necessary / suitable for the public at
large and
That's for the community at large to decide, not me :)
But given it has not been brought up before that I can see, the need for
it en mass seems doubtful at present, so unless you suddenly get a large
number of feature requests for it, I would say not necessary to make
change to the master code base.
> you'll patch your own installs as needed.
Yep, sure can as required.
Thanks again.
Re: RBL effectiveness (was Re: Ready to throw in the towel on email providing...)
On 30/07/2014 04:29, David F. Skoll wrote: originates from servers that RBLs cannot block for political or practical resons. Think Gmail, Hotmail and Yahoo servers, for This is the exact attitude as to why they wont get off their arses, because people think they are too big to block. be damned if I care, I have blocked yahoo and gmail before, and I dare say I'll have to again sometime.
Re: RBL effectiveness (was Re: Ready to throw in the towel on email providing...)
On Wed, 2014-07-30 at 09:12 -0400, David F. Skoll wrote: > On Wed, 30 Jul 2014 09:34:30 +1000 > Noel Butler wrote: > > > This is the exact attitude as to why they wont get off their arses, > > because people think they are too big to block. be damned if I care, > > I have blocked yahoo and gmail before, and I dare say I'll have to > > again sometime. > > You don't have paying customers for whom you relay email, do you? > > Regards, > > David. Certainly have done it on employers network before (a public ISP), and would have no problem doing it again if the need arose. There is no such thing as 'too big' when it comes to handling the shit storm of spam that gets spewed out of some organisations, and I'll treat Gmail and the likes the same as a ma 'n pa run outback country dialup ISP, there is no difference in my eyes, the fact that many see there is, is exactly why the likes of Gmail don't give a rats about spam complaints, if more operators started taking a stand, and directed their users bitching about blocked mail to Gmail etc, maybe Google etc, will pull their finger out of their ears (amongst other places) and not only listen, but act. It's in their interest to play nice, they make money by data mining every single Gmail users account, targeting, and advertising, if they keep getting blocked, less people will use them, they will start to notice the impact on their bottom line sooner or later. signature.asc Description: This is a digitally signed message part
Re: RBL effectiveness (was Re: Ready to throw in the towel on email providing...)
On 31/07/2014 11:36, Dave Warren wrote: There is a difference: Gmail is a very major source of wanted, legitimate mail. Most "may 'n pa run outback country dialup ISPs" are not. Most mail to most clients are a "very major source of wanted mail" Again, playing favourites is plain wrong, and it is exactly why gmail have the spam problems they do because again, they think they are like the "untouchables" and nobody dare do anything about them, well, when we blocked them, IIRC last time was for around 3 months, and a lot of angry emails from our clients to THEM, finally got their attention and they removed a handful of spammers, or so they eventually claimed. so yeah it took 3 months, but in the end, it got them off their arse. If you don't care about interacting with prospective or current customers, you might be able to afford to block Gmail. At $DAYJOB, we can't. Thats a stupid statement, it's because I do care that I take such actions, every SP wants to keep clients, cares and interacts with them, but clients these days actually have an IQ higher than most peoples shoe size, they know the world will always have a spam problem, they known full well SP's need to take whatever action they can to stop or reduce it, hell, they even expect it. 99% of users are POP3, if they were mostly IMAP, I would have other options, like just auto scoring all gmail messages high enough to always end up in Junk folders. Do you know the number of clients that argued blocking gmail for spam was wrong? None Do you know the number of clients we lost because of blocking gmail for spam? None
Re: SA works great!
Doesnt take you long does it Harry, you've been on this list a month and already your abusing and putting ppl down, calling child, telling to STFU, and some other tripe you levelled at Ted. Karsten already warned you once, I suggest you remember that. On 03/09/2014 06:52, Reindl Harald wrote: > Am 02.09.2014 um 22:32 schrieb Ted Mittelstaedt: > On 9/2/2014 4:59 AM, Reindl Harald wrote: just get a proper MTA, enable debug > logging and watch the commands / responses between client and server due a > message transmission and to make it clear for you: until after end of data > itslef is responded with success the message is *undelivered* and tried again > from the sendig client if it is a proper MTA However you have GIVEN THE SPAMMER AN OK that they have a valid victim address. You had to issue an OK to the RCPT TO: to get that DATA from them. You just told them "you got a good email address" child you do not realize that all you claim below has nothing to do with SA, nor did you understand how a *layered* spam protecton works nor did you try to understand *anything* i explained you so what - otherwise i had even accepted the message as you do your setup: * not on RBL * accept it and drop it silently because the score * issue "250 OK i even took the whole message" * how do you think you don't leak the RCPT case * frankly with the 250 OK you invite to send more spam my setup: * not on a RBL * reject it * don't issue "250 OK i even took the whole message"" * if it was not a spammer trigger a bounce on the senders server so that he don't think it was successful delivered and can even prove it by logs >> if your MTA *don't repsond with success* at END-OF-DATA the message implicit >> is counted as *not delivered* because simply in the middle of data the >> server could raised an error by a full disk or something else > Yes and the spammer just tries again. And again. And again, forever and > forever. so what - what has that to do with anything i explained and you refuse to understand over the whole thread? > The point of blocking on DNS or IP based blocking is to issue that error 5xx > because that is the ONLY thing that is going to cause the spammer to delist. > Because at that point they are now wasting money and time and resources > attempting to deliver to an address that probably does not exist. so what - that one was not on a RBL and now? accept the spam message or *reject* it? i at least reject it you accept it, say "250 OK" and then drop it silent > Sure they can parse the return code, looking for polite language saying > something to the effect "this email is being blocked because you are on > Wonkulating Gronkluator's blacklist" that some sites issue to "help" newbie > Postmasters realize that their mailserver is being hijacked, or something of > that nature. what has that to to with the topic? > But they GUESS so many of their victim addresses that they can't spend the > resources doing that on a dictionary attack, they KNOW that 99.99% of the > error 5xx's they get back are for User Unknown. So the few times they guess a > real address and get that polite human-readable explanation that they are on > a blacklist, gets lost in the noise. what has that to to with the topic? > But YOUR setup - why that's spam flypaper. Because, YOU are NOT issuing an > error 5xx on a sender IP that happens to guess one of your users email > addresses - because your just too curious to get at the DATA and inspect the > Subject: line. jesus christ - Subject is not data - subject is part of the header come back after you made it through *basic lessons* the client makes it to spamass-milter because he is *not* on the 15 blacklists in front of > Thus you are HELPING the spammers build a list of valid email addresses on > your domain. bullshit - i reject more than 90% like you but i don't issue "250 OK" for clear spam, i reject it > No wonder you have such spectacular spam counts. The spammers must just love > you. Your handing them over your user email list. sorry, but you are an idiot i handle nothing because the accept of DATA only happens if the client is not listed on RBL's and so you better stop to spread bullshit just because you don't understand what people exlaining you by wasting time with your posts > Sure, you may determine they are operating from a blacklist and shut them > down after they throw you 1,000 guesses from an IP address. But in so doing > you have handed them 10 good addresses that they will remember and just > attack you from somewhere else from bullshit again - more than 90% are rejected by postscreen and RBL's frankly postscreen can't leak valid addresses because it even don't know them - that information has only the smtpd process if you make it through RBL's and protocol tests > Do that a couple hundred times and they have thousands of your valid emails. > >> so the communication looks somehow like: * client: i am sending now
Re: SA works great!
Heh, yeah I know kids of today are so much worse then 20 years ago :) But either way, there needs to be drawn a line, so many newbies are scarred to post there newbie questions on so many lists because of people like Harry, he's got a long history of moderation and bannings, but, even I admit he has improved in recent times after I think finally accepting his actions are not going to be tolerated by many and is trying to change. On 04/09/2014 03:29, Ted Mittelstaedt wrote: > While I appreciate the support, Noel, I'm not in favor of banning > people from mailing lists for using what they think are insulting terms. > > Truth is that Harry's insults are really kind of cute, like the 6 year old > all decked out in a Jedi lightsaber doing battle with Darth Vader. > > My 16 year old son's insults could burn him to a crisp. Now that's > some seriously nasty stuff! > > Ted
Re: Spams with dot link or European Union suffixes
On 11/11/2014 12:23, Igor Chudov wrote:
> I am receiving a torrent of spam coming from dot-eu and dot-link
> domains.
>
> Those spams have perfectly correct mail settings, such as resolvable
> nameserver names, SPF, seem to all match.
>
> They also are all based on domains less than one day old.
urirhssub SEM_FRESH fresh.spameatingmonkey.net. A 2
body SEM_FRESH eval:check_uridnsbl('SEM_FRESH')
describe SEM_FRESH Contains a domain registered less than 5 days ago
tflags SEM_FRESH net
score SEM_FRESH 2.5
Re: 163.com
blatant spammers for well over _10_ years, I dont know one admin in APAC who has not blocked them a loong time ago, I also question the one of the largest in the world rubbish too, maybe from China's point of view they might be, but not from this part of the world On 13/11/2014 03:45, Joe Quinn wrote: > We've been getting hammered by spam from 163.com for quite a while now, and I > really _really_ want to blacklist it, but it's one of the largest websites in > the world. > > Everything I have found on Google points to them being blatant spammers, down > to the Wikipedia talk page. Does anyone else have them blacklisted? What > would the list recommend?
Re: ***UNCHECKED*** Re: Missing Modules
On 17/11/2014 04:49, Niamh Holding wrote: > WARNING: contains undecipherable part >RH> don't get me wrong but you need first to learn how to operate your OS >Condescending or what? In the context you quote - yes, but upon reading Harry's original - *no* it was not condescending (and he made a valid point)
Re: .co.at
On 24/11/2014 01:18, Matus UHLAR - fantomas wrote: > On 22.11.14 20:22, Igor Chudov wrote: > >> I have a special perl script, that I wrote, that scans emails, makes a WHOIS >> query via a perl WHOIS module, and looks at the creation date. > > this was already discussed and discouraged - you may get blocked at whois > servers. DOB is a RBL created for this use. Some people just enjoy re-inventing wheels :) The fact its worked this long tells me his server aint all that busy.
Re: Emails with extremely long URLs
On 24/11/2014 00:07, Igor Chudov wrote:
> On Sat, Nov 22, 2014 at 07:16:38PM -0800, John Hardin wrote:
> On Sat, 22 Nov 2014, Igor Chudov wrote: I receive spam emails that contain
> extremely long URLs, about 2,400 characters. I wanted to know if spamassassin
> has a rule that I can turn on to flag such URLs. I do not think that I ever
> receive legitimate emails with URLs that long. I don't think there's anything
> in the base rules but that should be pretty simple: uri URI_ABSURDLY_LONG
> /.{2000}/ Care to post a spample to pastebin?
Thanks. I do not currently have a sample. I will keep an eye on
them. They are MIME emails with junk plaintext content, and enormous
URLs in the html part.
Igor
As dumb, stupid, and ridiculous as it sounds, 2K chars is actually a
perfectly valid URL value
IIRC, most browsers accept up to 2100 or there abouts, but to put such a
URL in an email, would be asking for spam :)
Re: Honeypot email addresses
On 23/11/2014 20:12, Aban Dokht wrote: > On 22.11.2014 22:05, Ted Mittelstaedt wrote: > >> domain - I've seen user unknown messages for users who cancelled mailboxes >> on the domain over a decade ago. I figure 10 years of getting user unknown >> messages is long enough for any real humans and for legitimate mailing lists >> to remove those entries. > > From my opinion, this is not a good idea as you are going to put those > servers onto your list. > This way you'll blacklist bulk senders, with badly configured or even not > bounce management, but they are not all spammers! Surely though that is the senders problem. Also any sender - SOHO, medium or large business, government, or mass mailing specialists, who have no, poor, or broken bounce management, do deserve to be listed, to prompt them into getting their act together and fixing their code. Yes it happens, VMware are a perfect example of this incompetence, they still try send to an old list address of mine before I consolidated the 2 into this one, they have been getting user unknowns for about 8 years.
Re: Honeypot email addresses
On 25/11/2014 03:49, jdebert wrote: > No, let's not accomodate incompetent bulk mailers. It has never worked > before. All it does is allow them to continue to make excuses to fail > to do their job properly and it attracts spammers, politicians and > other such ilk. Spammers always take advantage of negligent and > incompetent mail admins. > > Blacklist, blocklist badly behaving mailservers, whether known > spammers or not. That is the standard policy everywhere. Exactly, those that care, quickly realise their error and correct their setup, those that don't, clearly don't care, so we don't care about them, why should we. Just like vmware in my case, it's only to me as far as I know, so I ignore it, but one day I might just have a few too many beers and change that ;)
Re: Confused by new version of spamassassin
How are you calling spamassassin? On 25/11/2014 20:53, Paul Gardiner wrote: > I drive spamassassin using spampd. I've just swapped from using opensuse 13.1 > to 13.2. That's taken me from spamassassin 3.3.2 to 3.4.0. I have two > confusing changes. 1) The really problematic one is that I no longer see > X-Spam-Level and X-Spam-Status headers in the processed mail. I do still have > X-Spam-Checker-Version. I was using status to trigger rejection, so now > effectively I have no filtering. 2) The confusing one: I used to have many > .cf files in /usr/share/spamassassin/. I now have none
RE: Argument "perl_version" isn't numeric
On 30/11/2014 21:23, Martin wrote: > -Original Message- From: Martin Gregorie [mailto:mar...@gregorie.org] > Sent: Sunday, November 30, 2014 11:08 AM To: users@spamassassin.apache.org > Subject: Re: Argument "perl_version" isn't numeric On Sat, 2014-11-29 at > 20:39 -0800, John Hardin wrote: But this effectively means we cannot add new > features to SA conditionals because they might do this to older installs. Can > SA set a $too_old flag to say that that the Perl version number check failed? > If so, it seems the me that, at runtime, it would be reasonable to exclude > new version-dependent features if either the $too_old flag is set or the > version number is lower than the feature needs. It would also be reasonable > for sa_update to report the exclusion since that serves to remind the > sysadmin to upgrade. Martin Personally I don't want any warning messages unless something has failed. Yesterday and again this morning I was getting warning emails every 5 minutes from cron jobs, which is really annoying. Will the file available via sa-update be the commented out one from tonight? Or do I need to turn sa-update off for a while? Martin huh? who doesnt null out cron these days and allow for in-individual-cron-file error reporting... but I hear ya, this current situation is unacceptable and should be rolled back without delay.
Re: Argument "perl_version" isn't numeric
On 01/12/2014 04:52, John Hardin wrote: > On Sun, 30 Nov 2014, Reindl Harald wrote: > Am 30.11.2014 um 05:39 schrieb John Hardin: On Sun, 30 Nov 2014, Reindl > Harald wrote: if that rule can't work in most environments and not made > conditionally it has to be dropped at all because it has more drawbacks than > benefits But this effectively means we cannot add new features to SA > conditionals because they might do this to older installs which new features? The perl version check in a conditional. Trunk SA supports doing that now. But if actually *using* that feature, even once it's officially released, results in unacceptable warnings in older SA installs, then at what point can the new feature *actually be used*? You do that with new x.MAJOR.0 release, where you can mandate minimum system requirements, currently this stunt has caused far more harm than what its currently worth and should be rolled back. You've been around a long long time John, so I know your not going to suggest people with production servers run a version from trunk just to satisfy a small few.
Re: Argument "perl_version" isn't numeric
On 01/12/2014 09:48, Reindl Harald wrote: > Am 01.12.2014 um 00:22 schrieb Noel Butler: > >> huh? who doesnt null out cron these days and allow for >> in-individual-cron-file error reporting > > everybody who want to face warnings before the get fatal > > frankly every part of our applications designed to run also in cronjob is > supposed to not output any single byte under normal conditions and so every > output resulting in a cronmail is a "fix that now" issue If the individual jobs are written correct, they too can output pre-fatal errors, I get where you are coming from though, for some it might just be easier to allow cron to report it, even then one could then still null out std output, but not std error, some things I like to get errors about, some things I want programmers to get notifications of that I don't want, others, I don't care too much for at all, its worked well for me for two decades but I know my approach is not for everyone.
Re: Argument "perl_version" isn't numeric
On 01/12/2014 11:10, John Hardin wrote: It has been. It's waiting for the normal masscheck process to generate a new rules update. That's excellent, thanks John.
RE: Argument "perl_version" isn't numeric
Had you read it, you would see that it is now corrected, or should be within hours. On 01/12/2014 20:08, Martin wrote: > I haven't read all this thread, since it went ballistic Sunday, too much to > read but there seems to be a misconception this is an sa-update problem from
Re: Argument "perl_version" isn't numeric
On 01/12/2014 19:25, Benny Pedersen wrote: > On 1. dec. 2014 02.06.51 jdow wrote: > >> The "if perl_version" line must be at least partially parsed so that the >> endif parsing works. > > Design faults, is spamassassin really that bad ? you are free to, ordinarily I'd say contribute to it, but knowing you Benny, I would enshrine a total ban on anything you submit anywhere, so I'll say my other response, you are free to not use it and find something else and leave us in peace.
Re: Argument "perl_version" isn't numeric
On 01/12/2014 22:27, Benny Pedersen wrote: > Please turn of html never going to happen
Re: Honeypot email addresses
On 02/12/2014 09:07, Reindl Harald wrote: > Am 01.12.2014 um 23:46 schrieb Franck Martin: > On Nov 26, 2014, at 10:50 AM, Reindl Harald wrote: > Am 26.11.2014 um 19:45 schrieb Franck Martin: My experience says it is very > useful > my point in context of that thread is that using previous valid addresses as > honeypot is dangerous to stupid - you have no clue in most cases about the > context how the RCPT got chosen and i know a lot of people sening once or > twice a year some mail to their limited address book > > congratulations if you in that case (you can't know) block the whole sending > server because one of your team memebers left not to mention the number of people who run ancient backups, because they CBF checking to see that their current backups still worked, and find they are mailing a dead address. Harry and I rarely agree, but here we do, it is a dangerous act - the only safe trap address are the ones never ever used before, its only way you have 100% guaranteed zero FP's.
Re: Argument "perl_version" isn't numeric
On 02/12/2014 10:24, Kevin A. McGrail wrote: > On 12/1/2014 6:06 PM, John Hardin wrote: > >> It looks like as long as we support perl < 5.10.0 then the only clean >> solution is can(Mail::SpamAssassin::Conf::perl_min_version_501) > > With perl versions so low in so many distros, I think we have to implement > the perl_min_version function. Do you want me to take a stab at it? > Regards, > KAM 5.10 is only what, six years old? Surely anyone running anything older have far greater issues :) (says the guy running a few slackware 13.1 boxes with 5.10.1 hehe but theyll join the 14 series this Christmas when I can take them offline to upgrade em, even -current is useing a 12 month old 5.18.1)
Re: Honeypot email addresses
On 02/12/2014 08:46, Franck Martin wrote: > On Nov 26, 2014, at 10:50 AM, Reindl Harald wrote: > Am 26.11.2014 um 19:45 schrieb Franck Martin: On Nov 26, 2014, at 10:19 AM, > Matthias Leisi mailto:matth...@leisi.net>> wrote:Agreed, > it is cheap in resources. However, it will be easier to add to a domain > blocking list than to add to an IPv6 blocking list. May be first line of > defense is the wrong naming. IPv6 blocking lists will be to remove the > extreme badness of the Internet "domain blocking list" is already done with > SpamAssassins URIBL only URLs found in the email, that's very limited. > blocking sender domains blindly is error prone because you penalty a legit > domain because some faced forged senders You think that spamhaus, SURBL, URIBL, and any other reputable list service would add in their blocking list a legit domain because some faced forged sender? I think they do know the difference, and even in the case they do collateral damage, they provide public resolution forms, as long as the sender knows how to resolve the block... Have you tried to block based on the domain in the envelope from or From: header? What is your experience? My experience says it is very useful. its useful to a point, but most spammers spoof, and you can spoof envelope headers easily, so unless your blocking a specific yahoo or gmail address, its pretty much a waste of resources blocking by host/domain names now days
Re: Honeypot email addresses
On 02/12/2014 15:28, Ted Mittelstaedt wrote: > On 12/1/2014 8:47 PM, Noel Butler wrote: > On 02/12/2014 09:07, Reindl Harald wrote: Am 01.12.2014 um 23:46 schrieb > Franck Martin: On Nov 26, 2014, at 10:50 AM, Reindl Harald > mailto:h.rei...@thelounge.net>> wrote: Am 26.11.2014 > um 19:45 schrieb Franck Martin: My experience says it is very useful my point in context of that thread is that using previous valid addresses as honeypot is dangerous to stupid - you have no clue in most cases about the context how the RCPT got chosen and i know a lot of people sening once or twice a year some mail to their limited address book congratulations if you in that case (you can't know) block the whole sending server because one of your team memebers left not to mention the number of people who run ancient backups, because they CBF checking to see that their current backups still worked, and find they are mailing a dead address. Harry and I rarely agree, but here we do, it is a dangerous act - the only safe trap address are the ones never ever used before, its only way you have 100% guaranteed zero FP's. This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Most honeypots are not used in such a draconian fashion. But go ahead and be Draconian - I guess the only way you both can justify a "win" on this argument is by assuming people use honeypots in ways that simply are not done in reality. For anyone else, this discussion about honeypots STARTED as a discussion on where to find good Bays feeding sources. Don't bother engaging the two Zealots, you will be wasting your time. Ted most dont use it this way ? backup your statement with evidence. I await your masses of proof do you even read what you dribble before click send?
