[HN Gopher] How to prevent email spoofing, using an unholy combi...
___________________________________________________________________
How to prevent email spoofing, using an unholy combination of silly
standards
Author : simon360
Score : 79 points
Date : 2021-08-15 20:33 UTC (2 hours ago)
(HTM) web link (simonandrews.ca)
(TXT) w3m dump (simonandrews.ca)
| gloryless wrote:
| lol, that's cause it's mostly for mail coming from your server.
| You probably don't see any of it
| anyfoo wrote:
| I still run my own router at home, and my own servers of various
| kinds. I put a lot of thought into my packet filter configuration
| for example, and overall my handwritten router and server stuff
| comes at a maintenance cost that I am happy to pay.
|
| Not so for email. It just stopped being worth it about 10 years
| ago or so. Regularly fine-tuning your configuration to not only
| not be marked as spam in originating mails, but to also filter
| incoming spam, walking the thin line between filtering too much
| and too little, was just no fun.
|
| I looked out for an email provider that provides the flexibility
| that I'm used to (multiple domains, catchall for subdomains,
| sieve filtering etc.), pay them a few dollars per month or year,
| and haven't looked back. My DNS is still homegrown and I
| handwrite my zones, but the MX just points to my provider.
| azornathogron wrote:
| Related: if you have a domain from which you never want to send
| email, you can also set up these records to tell receivers to
| reject everything.
|
| Here is a guide: https://www.gov.uk/guidance/protect-domains-
| that-dont-send-e...
| kureikain wrote:
| When implementing spam filtering for my email forward app
| (https://hanami.run) I was super confused at DMARC and as the
| author said. The DMARC keyword were all SEO-focus content by
| companies that aim for that keyword and didn't clearly give a
| definition of DMARC.
|
| Another confusion is the ARC, the acronym was alike so I though
| ARC has some relation to DMARC where they are totally different
| :).
|
| I think to help new people understand them, we should stop group
| DMARC with SPF/DKIM. SPF and DKIM are the thing you set up and
| you control. But DMARC is just a policy to tell the recipient
| what they should do if something failed SPF or DKIM. And it's
| totally up to recipient's mail server to support and follow
| standard of DMARC.
| relax88 wrote:
| The title seems a bit dramatic but I can see how this sort of
| stuff would throw anyone without a history of network or systems
| administration for a loop.
|
| This is one thing I really enjoyed about setting up ProtonMail
| with my personal domain. They make it really simple to validate
| that SPF, DKIM, and DMARC are set up properly.
| dang wrote:
| Ok, we've changed it to the (slightly less dramatic?) subtitle.
| Not sure which is the better choice here...
| simon360 wrote:
| I didn't realise that ProtonMail had DMARC built in. I'm kind
| of surprised more email providers aren't including DMARC report
| analysis out-of-the-box, to be honest.
|
| If Google Workspace/G Suite started pushing admins to use
| DMARC, and provided tools to make it easy, so many more domains
| would be protected, particularly in startup world.
| darkhorn wrote:
| Do you know any free email providers for custom domains that who
| provide DKIM?
| lstodd wrote:
| SPF, DKIM, DMARC... all useless.
|
| I somehow live without all those for what, since before they
| appeared. 2001 in fact. With my own MX.
|
| They are just ineffective bandaids.
| Denvercoder9 wrote:
| 83% of spam I received last month failed at least one of these
| checks, while less than 2% of ham did. They're certainly
| useful.
| lstodd wrote:
| IDK maybe it's my tendency to keep a low profile. Or some
| other perceptual bias.
|
| But in last 5 years levels of spam never even remotely
| approached levels what I remember from 2000s, when my job was
| actually fighting it (at an ISP).
|
| All this tech (SPF, DKIM, DMARC) came and went ... somewhere,
| and there was exactly zero impact in spam rates on the
| handful of domains I now maintain, when I did take some time
| to implement them.
|
| Nowadays I have a couple of my own domains, with nothing
| antispam-configured, and an gmail account, and you know what
| -- spam amounts almost exactly match.
|
| Hence the conclusion - it's not worth it to invest time into
| it.
| Urgo wrote:
| As long as you don't email anyone who uses a gmail address or
| uses google's email hosting (which is the majority of internet
| users now?) then you can get away with that. I did too (also
| having run an MX since around 2001)... but a year or so ago
| google started filtering all email which didn't comply into
| spam.. so.. had no choice but to set it up.
| judge2020 wrote:
| The point of these is to tie email reputation (aka. How much
| spam you send) to the domain sending the mail instead of the IP
| address doing the sending. You can still send mail without
| these set up, but real spammers might see it missing and
| impersonate your domain in their spam and tank your reputation.
| ttul wrote:
| Yet without DMARC, we would be far worse off.
| lstodd wrote:
| I doubt that.
| jeroenhd wrote:
| I disagree with the idea that SPF, DKIM and DMARC are somehow
| hard. They're all one-liners in DNS config that can easily be
| generated with some online tools if you don't want to read the
| standard. In my experience, correctly configuring mail server
| software is a lot harder than configuring the DNS to make your
| email arrive as reliably as possible. Obscure configuration
| formats are par for the course for almost every mail server
| setup.
|
| I've personally had a much harder time getting DNSSEC to work
| than I ever had issues with the various email DNS records. Even
| that is manageable if you're willing to Google around for a
| while.
|
| My solution to getting self-hosted email right is using Mailcow.
| A cheap VPS (Contabo FTW) plus Docker is all you need to get it
| to work, and it spits out all the DNS records you might need to
| add. That also includes autoconfig records for tons of software,
| which is nice.
| johnklos wrote:
| Ummm... DKIM is NOT a one-liner in DNS. It requires actually
| setting up, well, DKIM. The DNS part is simple, yes, but the
| DKIM isn't, and equating it to a one-liner in DNS is just
| simply not true.
| imron wrote:
| > They're all one-liners in DNS config
|
| $1 - turn the screw
|
| $9,999 - knowing which screw to turn
| SilverRed wrote:
| Thats why you use one of the all in one email software
| packages like mailinabox. They will configure all of this for
| you and show a dashboard telling you everything is good or if
| something is wrong.
| simon360 wrote:
| DNSSEC is in a whole different league. But I'd be very
| skeptical of putting a one-liner from a generator into my DNS
| without understanding, at least at a basic level, _what_ it was
| doing. Understanding that also means you can do some manual
| verification - take a look at email headers to see how mail
| servers are responding to your configuration, etc. etc.
|
| As for configuring a mail server, yes, that's definitely way
| harder. But these days, most companies outsource that to the
| likes of Google or Microsoft, until they get large enough to
| justify administering their own. There's exceptions to every
| rule, etc. etc., but every company I've worked at has either
| used G Suite or Office 365.
|
| The result being: many companies have email services running,
| but don't have anybody whose day-to-day is understanding how it
| works and how it's secured.
| jeroenhd wrote:
| > But I'd be very skeptical of putting a one-liner from a
| generator into my DNS without understanding, at least at a
| basic level, _what_ it was doing
|
| You're completely right, of course. In my experience, these
| generators usually explain what the generated code means,
| though. These records are a lot easier to read than they are
| to write if all you've got is a manual and a technical
| specification.
|
| I haven't used any hosted mailing services myself, but I
| can't imagine their control panels don't have either an
| option to generate the necessarily policies for you or an
| extensive guide on how you should configure these records and
| why. These records are the only part of the mail ecosystem
| these hosted platforms can't manage (unless you also let them
| do DNS) so they're a crucial step of the onboarding process.
| simon360 wrote:
| For SPF and DKIM, yes, you're right - most hosted services
| will generate those DNS records for you, and validate that
| they're set correctly in your DNS. But in my experience,
| they often don't mention DMARC at all, present DKIM as a
| "hey just do this don't worry about it" (which, given that
| it's cryptography... yeah, I don't necessarily disagree
| with that approach, don't scare people off), and often
| don't provide good SPF practices (~all vs. ?all vs. -all).
|
| On generators, a lot of them left me in an uncanny valley.
| They were supposed to make everything easier, but didn't
| explain the basic concepts, so I didn't know the values to
| even put into the generator. After I nailed down some of
| the basics, the generators just started making sense.
|
| YMMV. There's an infinite combination of mail
| hosts/servers, DNS providers, and record generators.
| Collating all that information the first time can be
| overwhelming, if DNS or email aren't an area of expertise,
| but I'm sure there's a low-friction path out there. A
| Northwest Passage of email security. I'd love to find it.
| scandox wrote:
| You're right - they're not really hard. Dealing with their
| consequences can be though. The real problem is that they are
| tacked on solutions...and that's why you end up with things
| like ARC
| (https://en.wikipedia.org/wiki/Authenticated_Received_Chain)
| which as far as I can see is a way of getting around the
| problems that DMARC creates for so many setups.
| sbuk wrote:
| The thing to remember is that these are useless unless the
| recipients MTA is configured to take action against failures.
| Another thing to understand is that very few services,
| commercial, public or otherwise, send DMARC reports, and many
| that do send very sparce reports that are as bad as not recieving
| anything at all. Fundamentally, catching spoofing, phishing and
| spam and not catching 'ham' is actually really hard.
| toast0 wrote:
| It's been years since I did it, but I added DMARC to a high
| volume domain and the reports were useful while I was adding
| it, to help make sure I didn't forget any authorized senders,
| but once I got that finalized, the reports were totally
| unactionable.
|
| I can't do anything about the attempted spoofs; I'm not going
| to track down everyone's open relays, and if I would, DMARC
| reports aren't really enough anyway.
|
| At the time, Yahoo, Google and Microsoft all sent reports,
| which is a good portion of email, although certainly missing a
| lot. I think there were a few other smaller names, which I no
| longer remember.
|
| Of course, it almost doesn't matter. Spam/phishing mail to our
| users still continued, they just stopped spoofing our address.
| It's not like very many people look at the domain mail claims
| to be from anyway; modern clients hide it, too.
| johnklos wrote:
| Thank you. We need more of this. Too many "how-tos" are written
| with too many assumptions and not enough common sense,
| straightforward explanations.
|
| I've set up and run all of these, but that doesn't mean that it
| doesn't frustrate the heck out of me whenever I have to deal with
| them. A good, handy reference like this will be quite useful.
___________________________________________________________________
(page generated 2021-08-15 23:00 UTC)