pascal07

Postmark shows the body for 45 days by default, and it can be extended to up to a year. https://postmarkapp.com/email-analytics

Hey there, Rian here (Head of Product at Postmark). We definitely understand the "mixed feelings" response for an acquisition like this. A couple things I want to reiterate:

* The entire Postmark team is joining ActiveCampaign, and we are going to continue to operate the way we have always operated for the foreseeable future. That includes the support team you love!

* We definitely don't plan to change any of the things we do to ensure the highest deliverability in the industry. We are not, for example, making any changes to the manual approval process—that will definitely continue.

Also keep an eye on the FAQ as we will be updating it throughout the day: https://postmarkapp.com/postmark-activecampaign-faq

Yep /batch is definitely the way to go! But feel free to reach out to support and we can take it from there.

> Are they able to live up to that promise?

Postmark product manager here, so I'm a little biased but... yes we are! You can see our Time To Inbox stats on our status page: https://status.postmarkapp.com/

We also have a handy migration guide here: https://postmarkapp.com/migration-guides/sendgrid

> On the other hand, postmark is a bit more flaky - I track delivery RTT and had had a few cases in my first year with them where Postmark had > 30m delays

Postmark product manager here... I'd love to know more about this. We publish our Time To Inbox on our status page: https://status.postmarkapp.com/

The only time emails might sit for longer than a few seconds is if there is some issue with the account (such a accidental spam being sent due to form abuse). If you have specific examples, can you please email support@postmarkapp.com and we'll look into it for you?

> although I find their API a little too slow to move everything over to them

Postmark product manager here... I'd love to know more about this. We publish our API response times on our status page (https://status.postmarkapp.com/), so this is a surprising comment. Can you email support@postmarkapp.com with your account details and we'll look into this for you?

Hey everyone, I'm the product manager at Postmark, and it's great to see all these stories. I'd love to find out a bit more about how y'all use the product. I can definitely send some T-shirts and other swag your way as well. If you're interested in telling your story, reach out to support and tell them you came from this thread! https://postmarkapp.com/support

Hi, I'm the product manager on Postmark, and wanted to chime in with a bit more of our rationale for mostly using shared IPs. With our exclusive focus on transactional email and high deliverability, an existing reputation is extremely important. By using shared IPs customers can leverage our reputation, which we police and protect heavily. And since transactional email has better engagement overall, it increases our deliverability even more. Most senders don't need dedicated IPs since an IP with no reputation is worse, so we believe it's better for the majority of our customers and their deliverability to use shared IPs.

That said, there is a case to be made for very large senders to have their own IPs. We agree with that. Our point is mainly that the vast majority of senders don't need it, and should rather use the stellar reputation of our shared IPs to ensure good deliverability.

If anyone would like to chat more, I'm happy to jump on a call - https://calendly.com/rianvdm/postmark-customer-calls/

The "as well off" phrase refers to "being equally compensated". So the absolute utility "number" remains the same. In order for that to happen, a decrease in the contribution that commute has on utility, needs to be compensated for by an increase in the contribution that one of the other factors (salary or rent) has.

A Hacker News comment thread about a post about Hacker News comment threads. It's meta all the way down.

> I feel like these "sins" are major shots in the dark with no real studies to back up such big claims.

As mentioned in the post, the claims are indeed based on real studies: observing users as they perform prescribed tasks in a usability testing lab.

As mentioned in the post, these are findings based on usability testing - direct observational research.

This is a silly article. It once makes the fatal mistake of equating design with "pushing pixels". Solving the problem is part of the design process. Silly linkbait is silly.

Did I mention it's silly?