Especially the part about "Rule of Thumb for Running Mail Server on a New IP Address
When you run a mail server on a new IP address, you should not use this IP address to send newsletters (aka marketing emails) right away. Instead, you should use this IP address to send transactional emails for a period of time to improve the reputation.
You may also want to use SMTP relay to send emails for a few days because SMTP relay services have a high IP reputation. After that, send emails directly to the familiar recipients."
Cool, I did not know that. Are there any other thinkable use cases of keeping messages in a hold queue for a longer period of time, for this option to exist?
Some sysadmins/postmasters do this to protect against spam floods. They use cron jobs to hold/release emails after validating the envelope contents using tools like MailScanner. Some use that for intercepting test messages [1] I don't have the links handy, but I have also seen some projects in github that utilize hold queues for managing more granular rate limits based on content rather than destination. Some anti-spam tools will also quarantine messages into the hold queue for review.
I double checked, and the confirmation links are sent to the sender as you would expect. Please check again and make sure you use the correct fields. If it happens more often, I'll consider swapping the fields, even though this order seems to make most sense looking at several email clients.
Instant messaging has become the standard. The messages I send my good friends have become shorter, and are often based on my expectations of their reply. With TardaMail, I wanted to recreate the letter-writing experience, digitally. Taking more time to write someone without expecting an instant reply can be very valuable, especially in these times of isolation.
Manual account activation because the "please click this link to confirm your email address" email somehow does not end up in my user's inbox, is one of the most frequent support requests I get.
I built an API (private for now) which offers a solution to these scenarios, and may work as an alternative to passive email validation.
Instead of receiving an email, users are asked to send an email to a unique email address to confirm their email address (this - by the way - also filters out temporary receive-only email addresses)
A proof of concept can be found here: https://confirm-email.progresso-ict.nl. I can imagine the API to be used for account creation, password recovery, signing up for newsletters, etc.
Even though, with a clickable mailto address, the amount of steps are equal or similar to receiving a confirmation email, my girlfriend tells me the method is cumbersome.
So, what does the HN community think? Other questions I still have to investigate are mainly security-related. Emails are spam-filtered by Amazon SES, yet have to test for spoofing.
very cool, awhile back I made a server router that helps me setup email address quickly: https://m8l.me/
This way I have a server to ignore all the confirmation emails.
If I understand the use case correctly, I give out your system generated emails instead of giving my emails correct? And then your service forwards all emails you receive to my email?
Looks cool, probably uses similar techniques indeed!
The use case of my API is not quite as you describe, but I get the confusion. Instead, my case needs the platforms at which you register to implement the new method of confirmation. That means you can't just use this for every existing software.
It goes like this:
- You register at platform A with your own real email address
- Platform A asks you to confirm your email address, but instead of sending you an email, it shows you an email address to which you can send an email.
- You send an email using your own real email address.
- Platform A receives an event from my API that they received an email at the given email address from the email address they expected, so email address confirmed.
What you see at the provided URL is simply a demo of what could be part of any registration form.
IPTV subscriptions are an alternative to regular cable tv subscriptions. It's linear tv streamed over the internet instead of it being delivered to you by your cable provider.
It's used for many reasons, but I personally got a subscription at an IPTV provider to be able to offer my French girlfriend to keep watching her French TV channels while living in the Netherlands.
That said, my service does not offer IPTV, simply an editor to users who already have their own IPTV subscription.
I've definitely considered it, and I use some custom plans for users who exceed the limits of the Pro Plus plan, but I think current prices are alright.
Also, keep in mind that these prices apply on yearly plans, and most paid users use monthly pricing, where prices range from $2 to $8.
I like your current prices. When I consider subscribing to something (rarely) I have to weigh something like a $10 / month cost heavily because I can only have a few of those total. But if the service is significantly lower ($1, $2.50 in your case) it's a no brainer. $5 would be in the middle somewhere as definitely easier to accept than $10.
It seems obvious that as a user I would like low prices, but at the risk of being slightly repetitive, what's apparently not obvious to many subscription service providers is that I consider the total price of all my subscriptions, not just the price of their one service.
> But if the service is significantly lower ($1, $2.50 in your case) it's a no brainer.
I think this rational is okay for selling things like a coffee or a mobile game but not for a service. If you're thinking of pricing this low, you really have to start targeting users that value what you're selling more or expand the product to solve more valuable pain points. If you've got a niche product, you're unlikely to sell a big enough volume to earn a living selling it cheap as well.
You'll lose the "no-brainer because it's so cheap" market by increasing prices but those customers aren't necessarily the customers you want.
Each additional customer costs 0 more (since its software), and it’s a side project, so maximizing revenue isn’t necessarily the OP’s chief objective. He made a cool thing, and people like it!
More customers means more support requests (especially if it's a cloud service) and customers that only get the product because it's cheap tend to be the noisiest and most unreasonable. The post mentions paying the rent with the earnings so I'm assuming more revenue is wanted too.
So long as overheads/support costs are low, having a cheap entry point has to be a good idea, if there's volume to be had. Especially if you have higher-cost options too for up-selling.
I agree with everything you said here. Except I'd emphasize the trick is to keep it still being a "no-brainer because it's so cheap" decision even at higher prices, by adding more value to the service as he goes (as you also said). Not necessarily with the same users, to be sure.
I like that you've decided that you're charging a fair price. While you certainly might make more money by raising the prices, you'll limit your market significantly.
I know that I use a TV related site (one of the ones for tracking shows), and as much as I'd be happy to pay them $12/year, their cheapest plan is 3 times as much, and I just don't see them as providing that much value to me.
Cheap indeed it is, but I guess that matches the target audience. IPTV is relatively cheap, and the service my tool offers is really a bonus and not a must.
More importantly, I don't think I would pay more than I am currently charging my users, so I think it's just fair. Also, I prefer a whole lot of small payments than a couple of big ones, and for now that seems to be going in the right direction.
I have an app that also went for $1 for a bit. People who are willing to pay $1 also pay $2.
If this was my app, I'd simplify the pricing a lot. Get rid of the free tier. People who aren't willing to pay for your service should go somewhere else. Instead, give people a free trial for 30 days or whatever.
I'd make it so:
$2 = mixture of your current Amateur + Pro, maybe call it "Basic"
$5 = "Pro" with all features
Simple is good. You don't need 4 tiers if your target audience is kinda price sensitive. 2 is enough.
I think this is good advice, but then I also think the current pricing is fair for what it does. If it did a lot more, then it could be priced higher.
I mean compare to say Spotify. Up to six people in a household can listen in their cars and any phone and any computer to any music pretty much, in fantastic quality with lots of features, for what $15 a month. Now that is worth $15 a month, as it's delivering actual content. That is a lot more value than an (admittedly compelling) editor that I just use to edit some preferences essentially.
"tardamail.com is too new, temporarily blacklisted" is what I see in the mail-logs.
Seems like something I can't do much about at the moment, and should correct itself in a while. It seems to get past most spam-filters though.
I'll consider implementing an email-confirmation backup, thanks!