3 ms·

Hosting your own email server is maddening. There are so many new things on top for validating that your email server is legit and does not send spam. On top of

Hosting your own email server is maddening. There are so many new things on top for validating that your email server is legit and does not send spam. On top of that, some email providers will derivate from the "standard" way of doing things right now and proceed to block you for mundane reasons. The only way you find out is one of your customers frantically telling you that their emails are not received by the other party. It will take you a few months to fix all those problems and even then it could be that some email provider decides to put new requirements in place.

kuschku 9y ago
DKIM, SPF, DMARC is all pretty simple, though. I’m running my own mail server with all those properly configured, and it wasn’t much work.
- narrowtux 9y ago
  Yeah I'm talking more about how every other mail provider has their own rules and you have to set it all up. Like one requires your mail domain to me an AAAA record (where I've used a CNAME) and other things.
  - kuschku 9y ago
    That's not just one, most require AAAA or A records. With SPF, DKIM, DMARC correctly set up, correct IPv4 and IPv6 reverse DNS, only A or AAAA or NS or GLUE records used in the entire resolution path, correct from and reply-to addresses, you should usually be good to go, though.
- e12e 9y ago
  But they are not all the same! I'm not even sure this cryptographic signed sender stuff is a good idea for email. But good look getting through to postmaster@gmail|outlook etc. But they'll hold you to some arbitrary standard that's supposed to mean "less spam" when they should have more than enough traffic to get by with statistical/ml methods anyway... /rant
  - kuschku 9y ago
    This cryptographically signed sender stuff is extremely important. DKIM+SPF+DMARC means you can prevent anyone else from impersonating your domain. Every MTA will reject mails that violate the DMARC policy you specify in your DNS, if you have any. All the old From: support@paypal.com scams are gone, impossible. This means spammers either have to use hacked servers, or their real From: address. And as soon as they have to use their real From: address, it becomes trivial to block spam. Blocking spam is only so hard because From: was basically meaningless until now.
    - e12e 9y ago
      Yeah well. It's email. Either the postcard is (cryptographically) signed by a personally trusted sender, or it's unsigned. It's not like impersonation is dead. When I signed up for the Gmail roll-out, security@gmail.com was reserved, but you can email me at sikkerhetsansvarlig@gmail.com - a poor Norwegian translation equivalent. More importantly, I can email you from that address, and tell you there's a problem with your account, could you please verify that your password is "hunter2", if not email your current password so we can verify that your account is secure (not that I ever have, or will, I got the account for a laugh). Federated trust (s/mime) or Web of trust/direct trust(gpg) secures email. All this domain pseudo secure dns nonsense... I'm not sure I accept it's better than static analysis.
      - kuschku 9y ago
        The point isn't to verify the account, the point is to validate that the account belongs to a certain server. If I get email from alice@example.tld, then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld. The important part in this is spam prevention, and that if I get an email from @paypal.com, knowing that it's real. What you're complaining about is another question, but not really relevant. Google always uses @google.com for employees, and if you get an email from that, it's real. This is about enforcing identification, not verification, security, trust, or anything else.
NoGravitas 9y ago
I agree with you in practice, though there's no reason that it has to be this way. Email, like other protocols of its age, is simple. What's difficult is navigating the forest of roadblocks set up by the big email providers to excuse them not accepting your mail (or not sending their users' mail to you). Most of these are alleged to have some purpose in preventing spam, but I think experience doesn't bear that out. They may prevent Joe jobs[1], and it may be reasonable to use the suspicion they create of a message being forged as one factor in deciding if a message is spam. But nothing really deals with spam except statistical analysis of messages. The real point is that the major providers are anticompetative, and that's not really the fault of email as such. [1] https://en.wikipedia.org/wiki/Joe_job https://en.wikipedia.org/wiki/Joe_job

kuschku 9y ago

DKIM, SPF, DMARC is all pretty simple, though. I’m running my own mail server with all those properly configured, and it wasn’t much work.

narrowtux 9y ago
Yeah I'm talking more about how every other mail provider has their own rules and you have to set it all up. Like one requires your mail domain to me an AAAA record (where I've used a CNAME) and other things.
- kuschku 9y ago
  That's not just one, most require AAAA or A records. With SPF, DKIM, DMARC correctly set up, correct IPv4 and IPv6 reverse DNS, only A or AAAA or NS or GLUE records used in the entire resolution path, correct from and reply-to addresses, you should usually be good to go, though.
e12e 9y ago
But they are not all the same! I'm not even sure this cryptographic signed sender stuff is a good idea for email. But good look getting through to postmaster@gmail|outlook etc. But they'll hold you to some arbitrary standard that's supposed to mean "less spam" when they should have more than enough traffic to get by with statistical/ml methods anyway... /rant
- kuschku 9y ago
  This cryptographically signed sender stuff is extremely important. DKIM+SPF+DMARC means you can prevent anyone else from impersonating your domain. Every MTA will reject mails that violate the DMARC policy you specify in your DNS, if you have any. All the old From: support@paypal.com scams are gone, impossible. This means spammers either have to use hacked servers, or their real From: address. And as soon as they have to use their real From: address, it becomes trivial to block spam. Blocking spam is only so hard because From: was basically meaningless until now.
  - e12e 9y ago
    Yeah well. It's email. Either the postcard is (cryptographically) signed by a personally trusted sender, or it's unsigned. It's not like impersonation is dead. When I signed up for the Gmail roll-out, security@gmail.com was reserved, but you can email me at sikkerhetsansvarlig@gmail.com - a poor Norwegian translation equivalent. More importantly, I can email you from that address, and tell you there's a problem with your account, could you please verify that your password is "hunter2", if not email your current password so we can verify that your account is secure (not that I ever have, or will, I got the account for a laugh). Federated trust (s/mime) or Web of trust/direct trust(gpg) secures email. All this domain pseudo secure dns nonsense... I'm not sure I accept it's better than static analysis.
    - kuschku 9y ago
      The point isn't to verify the account, the point is to validate that the account belongs to a certain server. If I get email from alice@example.tld, then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld. The important part in this is spam prevention, and that if I get an email from @paypal.com, knowing that it's real. What you're complaining about is another question, but not really relevant. Google always uses @google.com for employees, and if you get an email from that, it's real. This is about enforcing identification, not verification, security, trust, or anything else.

NoGravitas 9y ago

I agree with you in practice, though there's no reason that it has to be this way. Email, like other protocols of its age, is simple. What's difficult is navigating the forest of roadblocks set up by the big email providers to excuse them not accepting your mail (or not sending their users' mail to you). Most of these are alleged to have some purpose in preventing spam, but I think experience doesn't bear that out. They may prevent Joe jobs[1], and it may be reasonable to use the suspicion they create of a message being forged as one factor in deciding if a message is spam. But nothing really deals with spam except statistical analysis of messages. The real point is that the major providers are anticompetative, and that's not really the fault of email as such. [1] https://en.wikipedia.org/wiki/Joe_job https://en.wikipedia.org/wiki/Joe_job