Nice to see transactional email is coming! Great service, even though I use a reseller account to send around 10 emails a month. Every year I plan to close it, but man, it just works exactly as it should.
Is it an intended option that if you're on a promo plan that you can switch to the other size promo plans that were offered at the same time your promo plan was offered? (i.e. within the different promo plan sizes offered simultaneously on a BF.)
@Joseph said:
Is it an intended option that if you're on a promo plan that you can switch to the other size promo plans that were offered at the same time your promo plan was offered? (i.e. within the different promo plan sizes offered simultaneously on a BF.)
It should only let you change to a non-promo plan. Though I may have added some promo upgrade options to other promos in the past, I can't recall.
Do everything as though everyone you’ll ever know is watching.
TierHive - Hourly VPS - NAT Native - /24 per customer - Lab in the cloud - Free to try. | I am Anthony Smith FREE tokens when you sign up, try before you buy. | Join us on Reddit
You mentioned in the other thread you're setting up a dual 5090 box for spam filtering.
If you execute a model fine tune on spam, do a high quality write-up and post it on hacker news I bet you'll have a bunch of people discovering what mxroute is without it being overly advertise-y and hn has a fair few people with deep pockets reading it..
We trained a model to do X real world task will absolutely play well there if the technical execution is sound
ngl I wouldn't mind that. Sometimes curl commands are easier to understand than figuring out some supplier's webUI. But if you do API please let me lock the auth token to an IP
@AnthonySmith said:
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
@AnthonySmith said:
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
Mail baby insists on publishing your hosting server's IP, even if you are using Cloudflare.
@AnthonySmith said:
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
Mail baby insists on publishing your hosting server's IP, even if you are using Cloudflare.
That’s a really tough problem to solve in a friendly way and they’re trying to do it in a way that hosting providers likely already had in place with cPanel/DA hosting DNS.
@AnthonySmith said:
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
Mail baby insists on publishing your hosting server's IP, even if you are using Cloudflare.
That’s a really tough problem to solve in a friendly way and they’re trying to do it in a way that hosting providers likely already had in place with cPanel/DA hosting DNS.
I believe so.
Still, other providers seem to be able to do it. Your company, along with some other more marketing-centred (read spammer-friendly LOL) companies. Not sure about Amazon SES - but if memory serves me, no such requirements there either.
@AnthonySmith said:
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
Mail baby insists on publishing your hosting server's IP, even if you are using Cloudflare.
Until just a few years ago, we were fine with publishing the hosting servers IP. So what's the problem now? If you are worried about DDoS attacks, doesn't the network provider already protect you against it?
If you want information, feign ignorance reply with the wrong answer. Internet people will correct you ASAP!
It’s OK if you disagree with me. I can’t force you to be right!
@AnthonySmith said:
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
Mail baby insists on publishing your hosting server's IP, even if you are using Cloudflare.
Until just a few years ago, we were fine with publishing the hosting servers IP. So what's the problem now? If you are worried about DDoS attacks, doesn't the network provider already protect you against it?
Security comes in layers.
And with costs (in terms of resources and "extra hassle" - that's my registered term LOL).
Why would I remove a security layer which causes minimum extra costs and hassle just to satisfy the policy of an email hosting provider - knowing that it is an exception not a must (since other providers don't insist on that)?
Things and humans are imperfect. I will fuck up (another registered trademark there).
We will fuck up.
Why make it easier to fuck up?
That's because I have access to the mail servers. The better way to do it is a lot more work, and requires a completely new level of partnership with the hosting providers that use them. The absolute best way to do it is unique verification keys per domain in each domain's DNS, which means it's no longer just an SMTP transaction and also provides a similar path to IP discovery (find another domain with the same server key that isn't hiding their IP). The key would have to only approve the hosting server you're on while approving the domain with mail.baby at the same time. And that's just to achieve the same level of security that policy aims for. It's almost a new product at that point. I'm just not sure a desire to hide the hosting IP, for the number of people that truly care about that, justifies the development. Everything is easier when you control the originating mail servers.
When you don't control the mail servers, ensuring that only the specifically approved server is allowed to send mail from your domain is much more difficult, and there are plenty of reasons to not want a strict DMARC policy (but that being the only way you're going to enforce DKIM). Given the complexities around it, I have to say I think it's a fairly elegant solution. This is something on my mind a lot lately as I prepare a transactional system. Though it's not how I'll do it, I totally get the reason that was chosen.
I think in all of the TierHive development, engineering and testing work, the transactional email relay system was probably the thing that had the most time overall put into it.
It was an end to end nightare, switching debain and postfix versions halfway through was a disaster and tracking and limiting and providing evidence for end users, honestly, its MASSIVLEY over engineered, but now it works so well and is so feature-rich and self-maintaining I could practically have it taken out of TierHive as a separate product al la solusvm/virtfusion for email hosts.
It was honestly a massive mistake, we should have just allowed access to known external email relay services and lived with it, out of over 2000 active users, about 60 actually use the email relay, its a huge regret, the time could have been spent on IPv6 from day 1 instead.
But I am stubborn and once it was started.... well, here we are. I expected it to take a week, haha, you dont know what you dont know until you do, then its too late to back out.
TierHive - Hourly VPS - NAT Native - /24 per customer - Lab in the cloud - Free to try. | I am Anthony Smith FREE tokens when you sign up, try before you buy. | Join us on Reddit
Comments
Nice to see transactional email is coming! Great service, even though I use a reseller account to send around 10 emails a month. Every year I plan to close it, but man, it just works exactly as it should.
Is it an intended option that if you're on a promo plan that you can switch to the other size promo plans that were offered at the same time your promo plan was offered? (i.e. within the different promo plan sizes offered simultaneously on a BF.)
It should only let you change to a non-promo plan. Though I may have added some promo upgrade options to other promos in the past, I can't recall.
Do everything as though everyone you’ll ever know is watching.
I could look but I am in on my phone and old, do you or have you considered doing inbound only for resellers or use based via API?
Would be cool to plug that into TierHive, we have outbound transactional already.
TierHive - Hourly VPS - NAT Native - /24 per customer - Lab in the cloud - Free to try. | I am Anthony Smith
FREE tokens when you sign up, try before you buy. | Join us on Reddit
Not so much request, but suggestion
You mentioned in the other thread you're setting up a dual 5090 box for spam filtering.
If you execute a model fine tune on spam, do a high quality write-up and post it on hacker news I bet you'll have a bunch of people discovering what mxroute is without it being overly advertise-y and hn has a fair few people with deep pockets reading it..
We trained a model to do X real world task will absolutely play well there if the technical execution is sound
ngl I wouldn't mind that. Sometimes curl commands are easier to understand than figuring out some supplier's webUI. But if you do API please let me lock the auth token to an IP
It's an interesting thought. Though transactional will be coming this year and true to form, gonna give the middle finger to standard pricing models. That said, still not likely to compete with the likes of mail.baby, which I'm okay with because why hurt friends.
Do everything as though everyone you’ll ever know is watching.
Mail baby insists on publishing your hosting server's IP, even if you are using Cloudflare.
I see that as a security problem.
https://io.bikegremlin.com/32322/mail-baby-by-interserver-service-preview/#1-the-security-related-concern
🔧 BikeGremlin guides & resources
That’s a really tough problem to solve in a friendly way and they’re trying to do it in a way that hosting providers likely already had in place with cPanel/DA hosting DNS.
Do everything as though everyone you’ll ever know is watching.
I believe so.
Still, other providers seem to be able to do it. Your company, along with some other more marketing-centred (read spammer-friendly LOL) companies. Not sure about Amazon SES - but if memory serves me, no such requirements there either.
🔧 BikeGremlin guides & resources
Until just a few years ago, we were fine with publishing the hosting servers IP. So what's the problem now? If you are worried about DDoS attacks, doesn't the network provider already protect you against it?
If you want information, feign ignorance reply with the wrong answer. Internet people will correct you ASAP!
It’s OK if you disagree with me. I can’t force you to be right!
Security comes in layers.
And with costs (in terms of resources and "extra hassle" - that's my registered term LOL).
Why would I remove a security layer which causes minimum extra costs and hassle just to satisfy the policy of an email hosting provider - knowing that it is an exception not a must (since other providers don't insist on that)?
Things and humans are imperfect.
I will fuck up (another registered trademark there).
We will fuck up.
Why make it easier to fuck up?
🔧 BikeGremlin guides & resources
That's because I have access to the mail servers. The better way to do it is a lot more work, and requires a completely new level of partnership with the hosting providers that use them. The absolute best way to do it is unique verification keys per domain in each domain's DNS, which means it's no longer just an SMTP transaction and also provides a similar path to IP discovery (find another domain with the same server key that isn't hiding their IP). The key would have to only approve the hosting server you're on while approving the domain with mail.baby at the same time. And that's just to achieve the same level of security that policy aims for. It's almost a new product at that point. I'm just not sure a desire to hide the hosting IP, for the number of people that truly care about that, justifies the development. Everything is easier when you control the originating mail servers.
When you don't control the mail servers, ensuring that only the specifically approved server is allowed to send mail from your domain is much more difficult, and there are plenty of reasons to not want a strict DMARC policy (but that being the only way you're going to enforce DKIM). Given the complexities around it, I have to say I think it's a fairly elegant solution. This is something on my mind a lot lately as I prepare a transactional system. Though it's not how I'll do it, I totally get the reason that was chosen.
Do everything as though everyone you’ll ever know is watching.
I think in all of the TierHive development, engineering and testing work, the transactional email relay system was probably the thing that had the most time overall put into it.
It was an end to end nightare, switching debain and postfix versions halfway through was a disaster and tracking and limiting and providing evidence for end users, honestly, its MASSIVLEY over engineered, but now it works so well and is so feature-rich and self-maintaining I could practically have it taken out of TierHive as a separate product al la solusvm/virtfusion for email hosts.
It was honestly a massive mistake, we should have just allowed access to known external email relay services and lived with it, out of over 2000 active users, about 60 actually use the email relay, its a huge regret, the time could have been spent on IPv6 from day 1 instead.
But I am stubborn and once it was started.... well, here we are. I expected it to take a week, haha, you dont know what you dont know until you do, then its too late to back out.
TierHive - Hourly VPS - NAT Native - /24 per customer - Lab in the cloud - Free to try. | I am Anthony Smith
FREE tokens when you sign up, try before you buy. | Join us on Reddit
Some easy way to generate aliases from app or browser extension and the ability to reply from such aliases.
Why?
I'm pretty sure @jarland made an extension for one of the browsers, and a customer made one for another browser. I could be misremembering.
https://mxroute.com/extension/
Michael from DragonWebHost & OnePoundEmail