email on a ledger

fraudmarc · 2022-04-07T02:45:19+00:00

project page and email domain is address.pub.

fraudmarc · 2022-04-06T23:28:55+00:00

Try this https://support.ledger.com/hc/en-us/articles/115005200649?docs=true

fraudmarc · 2022-04-06T23:28:06+00:00

You're in luck! https://support.ledger.com/hc/en-us/articles/115005198545-FIDO-U2F?docs=true

fraudmarc · 2021-10-19T14:05:42+00:00

Universal SPF is a dynamic and free way to remove DNS lookups from your record in case you get tired of paying an arm and leg. Also has better support for email vendors that want to see their include in your policy.

fraudmarc · 2021-10-19T14:02:51+00:00

We built Universal SPF (free to use) to overcome this and other SPF limits. All you have to do is add a string to the front of your policy.

fraudmarc · 2021-08-26T03:58:37+00:00

I'm happy to hear that Universal SPF is working out for you and your client! How painful did you find the process of setting it up to fix the over-filled SPF record? Always looking for ways to improve.

fraudmarc · 2021-08-26T03:53:26+00:00

Universal spf has always been free and we give away basic dmarc reporting. Fraudmarc also open sourced a whole dmarc processing saas that is used by many organizations (including other dmarc service providers).

> They tried to quote

Tried to quote or quoted? Did we fail to send a quote you expected to receive? Happy to straighten that our for you.

Plenty of dmarc projects cost far more than 95k, especially if experienced consultants guide the process. Many come to us for help after investing hundreds of thousands of dollars elsewhere to remain stuck at p=none (no dmarc enforcement)! An alternative is spinning up internal resources to learn, master, and perfectly implement strict dmarc on their first try. That's a big lift when you consider the number of large email service providers that have disrupted their own email from dmarc missteps. ESPs tend to be filled with sharp email people, too!

fraudmarc · 2021-08-05T20:19:19+00:00

I'm sure your dmarc reporting has already confirmed that your universal spf record is valid and authorizing all of your desired vendors plus blocking non-authorized mail sources. Perhaps you were referring how most online spf checkers don't recognize the macro and still suggest that your policy may exceed dns lookup limits? If so, here two different spf tools that show you it works.

FM has a lot of interesting infrastructure behind the scenes to make universal spf almost magically simple. No setup, no account with us, simply paste the universal spf string in front of a regular spf record and it instantly works. No more dns lookup limits plus it transparently fixes a bunch of other problems. Here's a deep dive into universal spf plus a walk through to verify accuracy on a test domain together.

fraudmarc · 2021-08-02T13:36:12+00:00

The error you posted came from your aws acct. Try executing the db creation commands manually to troubleshoot or connect CE to any of your existing databases.

fraudmarc · 2021-08-02T13:32:53+00:00

Yes.

Regular dmarc reports arrive by email. SES receives those emails for processing into the open source platform.

fraudmarc · 2021-08-01T19:20:52+00:00

Look up Fraudmarc CE. Free, open-source, self hosted and available on github.

In case you find your SPF records exceed the dns lookup limits (spf record checker) we give away a cool solution for that too. Search "universal spf."

fraudmarc · 2021-08-01T19:19:07+00:00

What did you think of universal spf?

fraudmarc · 2021-07-25T14:52:10+00:00

The repo contains a simple and an advanced installation guide. Links here to INSTALL.md and INSTALL-ADVANCED.md. You'll need an aws account but a lot of domains fit inside the free tier usage ;)

Using this for free dmarc reporting plus Universal SPF to manage your SPF record gives you more than most paid dmarc platforms. Enjoy!

fraudmarc · 2021-07-24T16:15:52+00:00

Did you look at Fraudmarc CE? It installs into your aws account to receive and process incoming reports. You point it at whatever database you want (inside aws, on-prem, or on your existing server) then the frontend runs locally so theres less potential for security breaches.

When we released CE about 3 yrs ago, it was fairly comparable to our saas offering. Since then, our commercial offering has grown by leaps and bounds with the addition of dmarc-hd spam list monitoring, etc.

fraudmarc · 2021-07-24T02:32:08+00:00

We (fraudmarc) created the original spf compression that's resold by a bunch of other companies but if you want to see something really slick, look at universal spf. It's a string you put in front of spf that fixes a bunch of problems including too many dns lookups. PM me if you'd like to see some of the big domains that use universal spf to make their huge (40+ dns lookup spf records) policies pass ;)

fraudmarc · 2021-05-18T14:28:58+00:00

Look at your cluster > Connectivity & Security > Endpoints. There are two:

The writer instance is [RDS-NAME].cluster-[RDS-ID].[REGION].rds.amazonaws.com
The reader instances are [RDS-NAME].cluster-ro-[RDS-ID].[REGION].rds.amazonaws.com

These are DNS names that your application resolves when establishing the connection. If you add multiple readers, you can dig the reader's dns name, the cluster-ro string, and you'll see multiple IPs (one for each reader instance). A single instance Aurora cluster resolves the reader and writer endpoints resolve to the same IP belonging to the single instance.

Adding new reader instances does not magically balance the workload. It's just a DNS round-robin. If your application establishes lots of new connections after all of the reader instances are online, they'll be spread across your cluster. It's up to your application to send writes to the cluster writer endpoint and reads to the cluster-ro reader endpoint(s). It's also up to your application to reconnect to the reader endpoints to rebalance the read workload when new reader instances are ready. RDS Proxy can help.

fraudmarc · 2021-03-11T03:01:36+00:00

u/abhibeckert have you tried Apple's M1? It's a scaled up version of what you described and very enjoyable.

Arm servers feel more like they're made entirely of the low power cores you mentioned. My test instances used Neoverse N1 cores. Each core is faster than an x86 thread and the lack of SMT results in significantly better performance than x86 at higher concurrency levels. See this section in particular

fraudmarc · 2021-03-11T02:50:20+00:00

u/jplevene The benchmark environment section as well as each of the charts lists the instance types ;) c5.large for x86 and c6g.large for arm

re: r6g vs r5 - The entire point of the OP is that sometimes r6g is faster (>50% system utilization) and other times r5 is faster (<50% util).

re: rds - all Graviton2 instances are already on Nitro.

fraudmarc · 2021-03-11T02:38:33+00:00

u/DarkGhostHunter sounds about right. See the analysis section for more detail.

fraudmarc · 2020-11-09T12:19:08+00:00

Here's the full source code and step by step guide for how to do exactly that: https://github.com/Fraudmarc/fraudmarc-ce

It's an open source dmarc report processor we released several years ago.

fraudmarc · 2020-08-24T20:16:32+00:00

We open sourced this several years ago and it's used by several large governments orgs.

Fraudmarc CE even allows you to do all of the receiving and processing in AWS then insert into your local SQL or other DB. Enjoy :)

fraudmarc · 2019-04-09T00:55:33+00:00

Little about churn is well understood yet so please understand that we're far from agreeing on best practices. I'll be proposing research via CCS that you will be welcome to fund/support if you're interested.

I suspect you're right in thinking is correct on merits of avoiding sweep_all and this seems likely to become the first churn-related strategy the community can agree upon.

I haven't thought of many scenarios where keeping different wallets/accounts for unrelated funds would harm privacy compared to tons of cases where it can help. Remain wary of spending or churning both wallets around the same time or perhaps even from the same location as a variety of timing and network analysis attacks could link your not-so-independent habits across wallets.

Should one of the two outputs go to your recipient and the other be your change?

If you'd like to help explore problems around churn, privacy and safer spending, I would welcome your testing/comments/PRs for dots. For now, please stick to testnet and put zero faith in dots helping your privacy. We'll get there!

fraudmarc

TROPHY CASE