Re: [mailop] HELO *.*
On 11 Jun 2018, at 20:05 (-0400), Dave Warren wrote: On Mon, Jun 11, 2018, at 13:27, Brielle Bruns wrote: Been seeing an awful lot of these lately on one of my email servers (exim based): 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically invalid argument(s): *.* 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically invalid argument(s): *.* How would you blacklist *.* in a system that uses DOS-similar glob wildcard blacklisting? Is there any system that can blacklist a sender based on HELO/EHLO argument which can't use anything but DOS/shell style globs? Unless there is an escape character (unlikely), That is a startling assertion. this is likely very difficult to handle for an unskilled admin, and certain platforms will make this more difficult. What specific system are you thinking of? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] HELO *.*
On 18-06-11 05:05 PM, Dave Warren wrote: On Mon, Jun 11, 2018, at 13:27, Brielle Bruns wrote: Been seeing an awful lot of these lately on one of my email servers (exim based): 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically invalid argument(s): *.* 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically invalid argument(s): *.* How would you blacklist *.* in a system that uses DOS-similar glob wildcard blacklisting? Unless there is an escape character (unlikely), this is likely very difficult to handle for an unskilled admin, and certain platforms will make this more difficult. The answer is ?.? as most such systems do allow for "? matches exactly one character", but this is not particularly intuitive to a lot of less skilled admin types in the SMB/SOHO worlds. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop Which is probably another good thing why our spam auditors who have routines that can use that (as well as other identifiers) to auto add to reputation lists ;) Have seen a lot of attempts lately to use 'sneaky' helo's, not sure exactly what MTA they are attempting to fool, or in some cases even break, but there must be at least one platform or MTA out there that doesn't deal with it properly, (eg reject before it hits a client that can't deal with it) But most of the 'bulk' attempts we see with EHLO's like that are actually AUTH attempts.. so maybe they are trying something specific to an authentication mechanism out there, but less likely.. Auth blocking by EHLO/HELO is not something that is typically offered since it is so easy to forge.. but there might be a system that has some form of EHLO regex rules as part of it's permitted to auth mechanism.. that it is trying to fool... -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] HELO *.*
On Mon, Jun 11, 2018, at 13:27, Brielle Bruns wrote: > Been seeing an awful lot of these lately on one of my email servers > (exim based): > > > 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90 > 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically > invalid argument(s): *.* > 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140 > 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically > invalid argument(s): *.* How would you blacklist *.* in a system that uses DOS-similar glob wildcard blacklisting? Unless there is an escape character (unlikely), this is likely very difficult to handle for an unskilled admin, and certain platforms will make this more difficult. The answer is ?.? as most such systems do allow for "? matches exactly one character", but this is not particularly intuitive to a lot of less skilled admin types in the SMB/SOHO worlds. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] HELO *.*
I still see a lot of helo *.local which is supposed to be a multicast address, and sadly was the MS way. Not complaining to Michael directly as that was long embedded. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 > On Jun 11, 2018, at 7:21 PM, Brielle Bruns wrote: > > On 6/11/2018 4:23 PM, Michael Wise via mailop wrote: >> Back in the day ... I'd be inclined to not accept mail from something >> HELOing with an IP literal where the connecting IP was not on our local >> network. >> An excuse can be made for a mail client. >> An actual mail server doing this doesn't belong on the Internet until they >> buy a clue. >> IMHO only, of course. > > > You're not the only one who thinks along those lines. I'm glad by default > exim does sanity checking of the HELO/EHLO responses. Does a good job in on > itself blocking bots. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org/ http://www.ahbl.org > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] HELO *.*
On 6/11/2018 4:23 PM, Michael Wise via mailop wrote: Back in the day ... I'd be inclined to not accept mail from something HELOing with an IP literal where the connecting IP was not on our local network. An excuse can be made for a mail client. An actual mail server doing this doesn't belong on the Internet until they buy a clue. IMHO only, of course. You're not the only one who thinks along those lines. I'm glad by default exim does sanity checking of the HELO/EHLO responses. Does a good job in on itself blocking bots. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] HELO *.*
Back in the day ... I'd be inclined to not accept mail from something HELOing with an IP literal where the connecting IP was not on our local network. An excuse can be made for a mail client. An actual mail server doing this doesn't belong on the Internet until they buy a clue. IMHO only, of course. Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Got the Junk Mail Reporting Tool ? -Original Message- From: mailop On Behalf Of Brielle Bruns Sent: Monday, June 11, 2018 1:28 PM To: mailop Subject: [mailop] HELO *.* Been seeing an awful lot of these lately on one of my email servers (exim based): 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically invalid argument(s): *.* 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically invalid argument(s): *.* Anyone know if this is some sort of exploit or just the sign of a specific type of spambot? -- Brielle Bruns The Summit Open Source Development Group https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sosdg.org&data=02%7C01%7Cmichael.wise%40microsoft.com%7C6c1e72c8ac0c425470f208d5cfdb0279%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636643461903613377&sdata=W1u8ZacQ0ewi%2BdhRQsJ3m2Q%2BxyrSpIT10PF7SW2cRJc%3D&reserved=0 / https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ahbl.org&data=02%7C01%7Cmichael.wise%40microsoft.com%7C6c1e72c8ac0c425470f208d5cfdb0279%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636643461903613377&sdata=siKjMqZfU23hb1CKR7SjBVlcXg6WlQmR%2B5eHtsQGKwo%3D&reserved=0 ___ mailop mailing list mailop@mailop.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop&data=02%7C01%7Cmichael.wise%40microsoft.com%7C6c1e72c8ac0c425470f208d5cfdb0279%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636643461903613377&sdata=Rqn4G8JP7FZBvmJS7SUOYUMIQ4eyP%2FzcOXFitIcSI1U%3D&reserved=0 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] HELO *.*
On 18-06-11 01:27 PM, Brielle Bruns wrote: Been seeing an awful lot of these lately on one of my email servers (exim based): 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically invalid argument(s): *.* 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically invalid argument(s): *.* Anyone know if this is some sort of exploit or just the sign of a specific type of spambot? Looks similar to an implementation similar to the cutwail attacks.. It also could be an ISP, who's DHCP implementation, is telling DHCP clients that is their hostname.. But that is less likely.. especially given your example(s).. the second one doesn't look like something Seems to have dropped off.. (or we caught em all) Seen that for the last 4 months or so.. Comes from Windows based OS typically, so betting a 'bot' infection.. So far safe to just reject/mark on traffic to port 25 with that HELO/EHLO -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] HELO *.*
Been seeing an awful lot of these lately on one of my email servers (exim based): 2018-06-11 14:15:44 no host name found for IP address 157.25.104.90 2018-06-11 14:15:47 rejected HELO from [157.25.104.90]: syntactically invalid argument(s): *.* 2018-06-11 14:21:42 no host name found for IP address 185.221.172.140 2018-06-11 14:21:43 rejected HELO from [185.221.172.140]: syntactically invalid argument(s): *.* Anyone know if this is some sort of exploit or just the sign of a specific type of spambot? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?
On 10 Jun 2018, at 17:26, Al Iverson via mailop wrote: example.net IN MX 0 . Nice. It's been listed in a few best practice documents as well as RFC 7505 for more than a few years. Good to see it getting some traction. I cry a little inside every time I see a null MX, think of the lost opportunity to be handling it as a spamtrap domain instead. It's not a lost opportunity, it's aging. A null MX is like a charred white oak barrel for a mail-dead domain. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?
On Fri, 8 Jun 2018 at 18:14, Stefano Bagnara wrote: > On Fri, 8 Jun 2018 at 17:53, Michael Peddemors wrote: > > [...] > > And while using that as feedback might seem the logical conclusion, in > > the real world we still see more feedback reports from legitimate email > > the customer should have wanted, vs emails tagged as spam that are spam. > > Well, this is very surprising to me. Anyone else record similar scenario? Michael, I just noticed that I read your sentence in a wrong way. I read "more no-spam reports than spam reports" while I should have read "most of the spam reports received are submitted by mistake". So my previous reply was written after this misunderstanding. Now, if most spam reports are submitted by mistake by people that doesn't really want to complain/stop received emails from that sender then this make it even more important to be able to collect false positives (or are you telling that user-originated-feedback is not trustable enough that you can't use it for "false positives reports"?). On Fri, 8 Jun 2018 at 17:53, Michael Peddemors wrote: > IMHO, and the way most of our platforms are designed to work.. Empower > the users when you can.. but block the worst of the worst.. > > * Block at SMTP via RBL's that have very low false positive rates How can you tell an RBL have "very low false positive rates" if most of the users of that RBL use it at SMTP time (or if the "not-spam" reports don't flow to the RBL operator)? This is a dog biting its tail... I read "Very low false positive rates" as "Very low collected-false-positive rates" where we miss a "collected-false-positive against false-positives rate". In my small system I don't have a "false positive report", so If I silently drop 5% of the traffic randomly at the smtp level I hardly get any false positive report... this doesn't make the "randomly dropping 5% of the traffic" a good/trustable block. Most people don't know someone is trying to write them until they see the email and you get a false positive only when the sender phone-call the recipient to ask why he didn't reply (their next attempt only have 5% of chance to get blocked again, so 0,25% to block 2 sends, and they won't care to call me to complain). Even if you have a good "rate" you could have a bad statistical distribution (see my B2C vs B2B example at the end of this reply). I don't want to delegitimize those RBL, but the "false positive loop" is one of the key aspects of an automated system and its importance increases as the "spam report loop" quality decrease. IMHO today there are major holes in the false positive loop and this didn't improve at all through the years. How can the quality of the spam report loop be low? 1) you get it from the final user and, just like you told us, most of them don't use this feature correctly. 2) you automate it with no "volume comparison", so you only evaluate reports and not "everything else" 3) you works with hashes/fingerprints instead of full messages (it's harder to manually review listing/delisting from something you can't really "read"). Why is this "in topic"? 1) IPv6 enable more "scattering" and IP based RBL are less effective for low-volume senders (the lower the volume, the lower the statistical significance, the higher the error) 2) If you move to a fingerprint (content) based blacklist and you do that working mainly with hashes (like CloudMark Authority) you don't know anymore what you are really going to block, until you start blocking it. I'm sure CloudMark (CA: CloudMark Authority) have major "false positive loops" but I'm aware of multimillion-inboxes-providers using it only to block emails and to send "spam reports" (no false positive report loops). To name names, in Italy "Libero.it" (ItaliaOnLine) the largest italian inbox provider (10-15 million inboxes) uses CloudMark and AFAIK send them spam reports, non-spam reports and (I'm less confident about this, but I think they do) "volume data" about fingerprints and they never reject at SMTP time because og this. On the other side "Aruba" the largest B2B italian inbox provider (7 millions inboxes) uses CloudMark and AFAIK send them spam reports, DO NOT send "non-spam reports" and on recipient option they may reject emails (not at SMTP time, but via bounce... but the recipient doesn't get the email). So, if you do B2C or mixed B2B/B2C to Italy Cloudmark works mostly well (they easily block fingerprints, but then they get false positive reports and unblock), but if you only do B2B traffic you'll often hit some Cloudmark block with many false positives that are not collected by Cloudmark that can't never decide to unlist on its own. PS: I talk about CloudMark because I happen to have good knowledge of that filter and I think it is one of the "smartest" filters out there WRT to distributed content filtering and I think it is "100% IPv6 ready" as its design does not depend on IPs (they have "Sender intelligence" for that), but still show issues. And yo
