Re: [mailop] IP to country?
On Mon, Apr 24, 2023 at 06:44:45PM +0300, Mary via mailop wrote: > Is there a place that provides IP to country location information for free? Yes. Here's a (Python) script you can download and run for yourself, if you wish: Generating country IP ranges lists http://blog.erben.sk/2014/01/28/generating-country-ip-ranges-lists/ Scroll down a bit to "UPDATE" and "UPDATE2" to find the freely downloadable output from the Python script (see link below) as well as a PHP script that uses Maxmind to generate the lists in anothe way. Or if you want to skip right to the goodies: Country IP ranges http://www.iwik.org/ipcountry/ ---rsk ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] emailage.com ?
On Mon, Apr 24, 2023 at 10:44:47AM +0200, Jasper Spaans via mailop wrote: > We're seeing quite some postfix PREGREET errors in incoming smtp traffic > from hosts claiming to be emailage.com (by lexisnexis). Does anyone know > whether this is just a dressed up list washing service, or would it be > worthwhile for our customers if we start whitelisting them? I'm still investigating, but my PRELIMINARY understanding is that this is a poorly-thought-out "service" run by Lexis-Nexis. If that understanding is wrong, and five minutes from now it may turn out to be, then I apologize. But: I believe it's trying to use SMTP callbacks to verify email addresses, and that's abusive -- as well as pointless. We went through this 20+ years ago when Verizon foolishly deployed them as a putative anti-spam measure even though they have no anti-spam value whatsoever. Nor do they have any anti-phish, anti-fraud, or anti-anything-else value. Those of us [1] who analyzed them at the time pointed out the inherently abusive nature of this as well as how it could readily be used to conduct third-party attacks. I haven't re-read those message threads in a long time -- because I thought that we'd put enough stakes through the heart of this terrible idea that it would never rise again -- but perhaps that was wishful thinking. ---rsk [1] Myself, the late Bruce Gingery, and if memory serves, Steven Champeon, among others. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
On Tue, Dec 08, 2020 at 10:58:22AM +, Paul Smith via mailop wrote: > "Typographically similar" is not "identical". Yes, many people will be > fooled by "typographically similar", but not everyone. SPF (and DKIM) allow > you to verify to some level of certainty that the sender is who they say > they are if you want to try. Without them, you have no chance. First, "similar" is more than enough to fool almost everyone. Presume that example.com is, let's say, a financial institution. If example.TLD (where TLD is any of the myriad new ones) isn't available because example.com decided to get there first, then example.com.TLD or example.comm.TLD will probably suffice. (I know, because I've run the experiments while doing penetration tests. BTW, this works a lot of the time even when the targets are people who work for example.com and should ostensibly know better. Guess what? They don't.) Second, suppose that you can verify the sender. So what? Even if this verification is completely reliable -- and it's not -- it doesn't tell you what their intentions are. Or will be tomorrow. [1] Third, neither SPF nor DMARC nor anything else can be relied on if the email account or email host is compromised -- and we see instances of that constantly. In other words, if financialoffi...@example.com has been compromised then the new owner of that email account can send anything they want and it will be dutifully "verified" by anyone naive and foolish enough to believe SPF et.al. provide verification. (Should I remind everyone that *every* Yahoo account was compromised and that *every* message those accounts sent was "verified"? And this is hardly an isolated case.) SPF et.al. are failed attempts to wallpaper over a massive underlying security problem that has gotten steadily worse for most of two decades. They pretend to provide "verification" in an environment with hundreds of millions of bots [2], mass compromises of individual email accounts, and a steady stream of security breaches of mail servers of all shapes and sizes. It's a pretend game. It doesn't actually address the root cause(s). And that's because fooling around with SPF et.al. is much easier, much simpler, much cheaper than actually tackling the underlying problems. ---rsk [1] Everyone should know by now that even if a network/host/mail server/ email account is benign today, that in no way ensures that it will be benign tomorrow. [2] Probably more like a billion by now, but let's gloss over that and note that anyone who controls a bot controls all email accounts used/stored by the bot's previous owner. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Effeciveness (or not) of SPF
SPF is just about entirely useless, which should surprise nobody. This was obvious on inspection when it was announced. - It's no help with spam: almost without exception, every message that hits my spamtraps passes SPF. - It's no help with phishing: thanks to ICANN, registrars, and the proliferation of TLDs, phishers have their choice of hundreds of millions of typographically similar domains. Or they can just use freemail providers and rely on the gullibility of recipients. - It's no help with forgery for the same reason, and for another: mass compromises of email accounts are commonplace (see: Yahoo). It's never worked. It's not working. It's not going to work. And about this: On Sun, Dec 06, 2020 at 02:12:25PM +0100, Hans-Martin Mosner via mailop wrote: > (I know mail users should not simply forward their mail It worked perfectly well for decades until it was broken...for nothing. ---rsk ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Reasons to add plain text alternative to email?
I've said this many times and many places, so I'm going to apologize to everyone who's already read it and knows where this is about to go. HTML markup in email is used by three groups of people: 1. Ignorant newbies who don't know any better 2. Ineducable morons who refuse to learn 3. Spammers There are no exceptions. HTML markup is almost always horribly broken, bloats messages tremendously, introduces security and privacy issues, makes messages less searchable, and adds nothing to the process of communication. (It is notable that quite often the extracted bodies of messages marked up with HTML are riddled with spelling, punctuation, and grammatical errors in addition to being poorly composed. Adding HTML markup to these messages like sprinkling fresh mint on a steaming pile of manure and pretending it's now an acceptable menu item.) If you (generic you) can't communicate in plain text, then you can't communicate. Nothing you have to say is worthy of an audience. And as an aside, anyone who who functions in a professional capacity, e.g., a system administrator or network engineer or similar role, and thus shares responsibility for the security of the operation(s) they manage, should always use a text-only email client. If it's not clear why, then recall the lesson accidentally taught by RSA. ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
On Thu, May 09, 2019 at 09:26:50AM -0400, Rob McEwen via mailop wrote: > you should strongly encourage your customers to > captcha-protect their signup forms to prevent bots from signing up spamtrap > addresses. No, you shouldn't. I'm going to quote something that I just sent elsewhere, so my apologies to anyone who's seen it. Captchas are a worst practice. They can be and are defeated at will by any adversary who can trouble themselves to do so. [1] They're security theater: think Wile E. Coyote holding an umbrella over his head while a boulder drops toward him. [2] Worth noting as well are (a) the continued and accelerating convergence of the trend lines denoting "captcha hard enough to defeat automation" and "captcha easy enough to be solvable by humans" and (b) the onerous additional burden that these often place on people who have diminished eyesight and hearing, who are part of different cultures, etc. There are far better ways to defend resources, and -- judiciously deployed -- these methods are not nearly as susceptible to adversarial manipulation, nor do they make life more difficult for people whose lives are arguably difficult enough already. ---rsk [1] Here's an example of what I mean by "defeated at will": Wiseguys Indicted in $25 Million Online Ticket Ring | Threat Level | Wired.com http://www.wired.com/threatlevel/2010/03/wiseguys-indicted/ [2] A partial list of references follows. Do note that the contemporary state of the art in captcha-defeating techniques is much more advanced than any of these suggest. Of course it is: attacks always get better - they never get worse. (h/t to Bruce Schneier) Also, there's plenty of funding -- see footnote [1] above -- available to support research and development in this area that will NOT be helpfully published in blogs or journals. So consider what is enumerated below as the lower bound of what *was* possible and extrapolate markedly upwards to estimate what *is* currently available. Stanford researchers outsmart captcha codes http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html CIntruder: pentesting tool to bypass captchas http://cintruder.sourceforge.net/ How a trio of hackers brought Google's reCAPTCHA to its knees | Ars Technica http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/ Snapchat Account Registration CAPTCHA Defeated - Slashdot http://it.slashdot.org/story/14/01/23/2037201/snapchat-account-registration-captcha-defeated Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html Troy Hunt: Breaking CAPTCHA with automated humans http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html Slashdot | Now Even Photo CAPTCHAs Have Been Cracked http://it.slashdot.org/article.pl?sid=08/10/14/1442213 Cheap CAPTCHA Solving Changes the Security Game https://freedom-to-tinker.com/blog/felten/cheap-captcha-solving-changes-security-game/ unCAPTCHA Breaks 450 ReCAPTCHAs in Under 6 Seconds https://www.bleepingcomputer.com/news/technology/uncaptcha-breaks-450-recaptchas-in-under-6-seconds/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Howto be a good mailop (best practice / insights wanted)
I'll have more to say on this (of course I will ;) ) but I'll mention that I'm attempting to assemble what I'll call, for lack of a better term, a roadmap of RFCs that mail system operators should be familiar with. I'm doing this because I'm trying to (a) train some junior people and (b) fill in gaps in my own knowledge. I'll likely ask ietf-smtp and mailop to both review it because I have no doubt that I'll overlook some that should arguably be included. Once it's put together, perhaps it would be useful to all of us. (Modulo those people who've already read them all and can quote them at length from memory. ;) ) ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] DigitalOcean calling for social media s* storm? (Re: Why is it so hard to have takedown's performed..)
On Mon, Apr 29, 2019 at 03:54:41PM +0200, Benoit Panizzon via mailop wrote: > I wonder if DigitalOcean is running for some social media related > wake-up call. It would be far easier and much more effective if everyone on this mailing list caused every mail server that they run to refuse all mail from all Digital Ocean network space without warning, effective immediately, remaining in effect until such time as all open issues have been addressed, apologies have been made, and a convincing plan for prompt future action put forth. After all, there seems little reason to continue extending them the privilege of access to mail (and other) services when they repay that largesse by abusing it on a mass scale. And my guess is that a concerted move of this nature would get their attention in a matter of hours and that long-overdue remediation would quickly follow. (And if not? I don't see a problem with letting them enjoy their intranet. That might be the best outcome for all concerned.) Alternatively, we can continue to note the chronically, systematically, deliberately abusive conduct of Digital Ocean for another decade or two. ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] forwarding failure, Admin: Gmail users of mailop suspended due to bounces.
On Thu, May 02, 2019 at 11:50:12AM +0100, Andrew C Aitchison via mailop wrote: > With single-sign-on I need to make it easy for users not to give the > alternate mail service (and their hackers :-) access to all the > services I provide, along with POP retrieval. In addition: thanks to password re-use practices, which are epidemic, "giving provider $X a password so that they can POP email from provider $Y" is semantically equivalent to "giving provider $X passwords to some/most/all other accounts of other descriptions". Even if we presume the most scrupulous behavior by $X and its personnel -- and history shows that is often naive and dangerous -- it still increases the exposure/risk of the password in question. ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.
On Sun, Apr 28, 2019 at 11:33:07AM -0600, Brielle Bruns via mailop wrote: > A slack channel would be cool regardless [...] No, it wouldn't. You might find it instructive to read their S-1 filing, referenced here: Slack Warns Investors It's a Target for Nation-State Hacking https://motherboard.vice.com/en_us/article/pajbj8/slack-warns-investors-its-a-target-for-nation-state-hacking which I strongly suspect is far more likely to be history than merely well-informed speculation. ---rsk ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
