Cloudron Forum

@micmc Can you share one of the domains so I can have a look?

@girish Your logic really opens this up and I get it. You guys know your users and if "outbound-only" folks are managing their own DNS, then it definitely would't make sense. I was just concerned for the less experienced.

I'd say we could close out this thread.

@brutalbirdie Don't fret, big guy. If you're using Cloudron to manage your incoming e-mail then you are covered. DMARC is implemented in Cloudron... it's just in the wrong place. So if you're an inbound or inbound AND outbound user then you are safe. Outbound only users should create a DMARC policy manually to take advantage of this feature until it's resolved.

@brutalbirdie Absolutely... and goood choice with Cloudron! And I'll do my best to keep it light.

DMARC is sort of a mashup policy that enforces DKIM and SPF records. Don't run away yet...!

DKIM is a method where each e-mail you send is signed with a private key. When a recipient's server receives your message, it compares that key against a public key that you publish via a DNS record (that way it's available to the entire web). It's one way of verifying that an e-mail actually came from you.

SPF is another policy published via DNS records that tells receiving servers which sender domains and IP addresses they should consider valid senders. It prevents bad actors from spoofing your domain by saying only accept mail from my Cloudron instanse which is on my.brutalbirdie.com.

With DMARC, you publish another DNS record that lets receiving servers know you are serious about your e-mail identity. If an e-mail sent by your domain doesn't match a DKIM or SPF record, then you can instruct them to reject or send that message to SPAM folders.

In all, DMARC is another method of building trust for e-mails that are sent. Last year, the FBI reported losses in the billions from impersonated e-mail. By properly adding DMARC to outgoing DNS settings, you'll better protect your recipients and your brand.

Let me know if I missed the mark anywhere for you.

Currently in Cloudron, DMARC DNS records are generated when inocming e-mail is activated.

What's missing is that DMARC policies are set by the domain owner (e-mail sender) and should be generated alongside DKIM and SPF. E-mail recipients only choose to acknowledge and honour the policy set by the domain owner. If it's not a terrible amount of work, please consider correcting the method of TXT record generation for DMARC. This will protect users that choose "outgoing only" as e-mail option for apps.

@robi That's a great idea... I was just head-scratching that myself. Having this info would be great to assist with scheduling crons.

That said - If you would like a quick fix, the info is already there (sort of).
Just do this:

• Log in to your Cloudron panel and select "Event Log" from the panel under your username.

• Find the last "Backup Started" cron event in the list.

• Use your pointer to hover over the value in the "Time" column that event.

• You should now see all of the event details including the exact start time.

• Do the same for the "Cloudron backup created..." event.

With some simple math you should get some insight into how long your last backup took to complete. I hope this helps.

That's great work @girish - it's not often you step out for the day and return to see your post "solved". I was going to include that it should be a simple nginx config thing but I know better. And it's unfortunate the request caching is a nightmare to enforce "must-staple".

Regardless, the win here is that you have it enabled. That should now be reflected in test reults from Mozilla Observatory (extended to Qualys SSL Labs & ImmuniWeb). Thanks for putting in the grunts on this one.

It's not mission critical but it would be nice to see support for this NIST/HIPAA recommended protocol.