New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Wait wait wait, so this isn't a Fran's fault? Well damn, that's a nice change.
Francisco
We didn't do anything today. mail.baby does not use MailChannels to send traffic anymore (see above). Reviewing their status page, here's what I conclude - please correct me if I am wrong:
mail.baby blocks emails based on the spam score they are assigned by rspamd (an open source spam filter). It seems that they are now trying to block emails from compromised senders as well using a plugin (presumably an rspamd plugin?). There were problems with the plugin, apparently due to scaling. They got some help from someone who commits code to the rspamd project and have added machines to help it scale.
In any large email sending service, you must have a way of rate limiting or blocking senders based on signals about their behaviour that you gather from delivery logs and old spam scanning results. Doing this at scale is a tremendously hard problem. At MailChannels, read and write >100K behavioural datapoints per second in an effort to pinpoint abusive senders from the moment they turn bad -- that's 26 billion reads and writes per day. This system allows us to turn around information from an abusive sender to block that same sender in under one second.
The reads have to be extremely fast because many metrics must be read during each stage of email processing. Behind the scenes, every SMTP connection at MailChannels is processed by up to 100 or so policy scripts, each of which may read some metrics from the behaviour tracking database to make a decision before the next phase can assess the connection and message. Our average total policy script execution time is just 11ms; that includes all of these behavioural lookups, evaluating thousands of regular expressions and string matches, and looking up other things such as account and licensing information.
Scaling email is very hard work. rspamd is great, but you need so much more scaffolding around it to run at scale.
My comment was a little sarcasm, since i know the relationship ended some time ago between both of you.
Baby mail is toasted without mc. Sad, it was good service.
Great, and then we have to ticket almost every day complaining about users getting blocked. Support then tells us its a false positive. But, at least we have 100 Billion data points to reference. At that point I have no doubt you're running into the 'cant see the forest for the trees' where you're so overloaded with data that it's just all noise.
Or, the fact you can commit a financial DDOS on a users account and MC only does something once loud mouths like myself make an absolute stink about it in ticket. I can only imagine how much over charging has been done to large clients unaware of this one.
MC is great when it works. It caused a lot of grief though, which hurts even more with the yearly price increases.
Francisco
... mailcrane.com maybe?
No, I don't think i'd ever want to offer an SMTP relay product. I'm far too dumb when it comes to mail (amongst most other things) to do it well. I've been slowly working on our own relays and I have to lean pretty heavily on Jarland for pointers/feedback.
I think the only mail product we'd ever really offer would be email accounts along side domains.
Francisco
Gf> @Levi said:
I thought you said it's not possible to run such a service without mc. Or did you mean that mail.baby can not do it but you fully believe that Francisco can? Or are you imagining a scenario where "mailcrane" would use mc in the same way that mail.baby was not allowed to do?
There’s little point in trying to outcompete @jar as things stand, imo. That said, I wouldn’t mind a bare relay type product vs. the current setup.
It’s clearly possible to run such a service without MailChannels, and mail.baby serves a similar market fairly well (where delivery may not be 100%, but best effort is enough).
Do you feel that mail.baby can successfully offer the same level of service without mc, as it did with mc?
No one is getting 100%.
Where is the Yabas for mail delivery? I want to see real data.
MC representative provided .png with 1B sent messages and delivery success rates. It is unreal data?
if you belive the graph made by a competitor you should check out the mail delivery video we made here
Your data point regarding delivery denounced by baby mail. Have you anything to say here?
Depends what you consider the service to be. Did anyone realistically expect near perfect delivery rates before, and this is no longer the case? I'd say the service has always been best effort and it remains so.
Sorry about the bad experience you had, Francisco. One of the areas we are investing in right now is using generative AI to improve our capacity to review accuracy issues. At present, while we do use a lot of automation to process false positive reports, there are still areas in which human intervention is required.
We look forward to bringing a number of significant improvements forward in the coming months that will greatly speed up the resolution of accuracy issues.
Sure, AI makes the stock holders moist. I get it.
We'd had been with Mailchannels since 2017~2018, so we weren't a new client. We probably would've stayed with you guys if we didn't have to deal with the attack method I mentioned. Baby is cheaper by half, but we would've left it alone if it was working as intended.
Fact of the matter is we couldn't even do a single full run of our billing invoices without getting constantly blocked and then having to ticket for an unblock. We have to use mailgun for our billing runs. I get you guys are extremely concerned about outbound spam, but your AI's borderline braindead if it keeps overreacting like this.
Francisco
>
Sure, I'd be happy to provide more insight into how the graph above was generated.
MailChannels runs an inbound filtering service that hosting providers use to filter incoming email before it hits their webmail customers' inboxes. To generate the data for these three charts, I created a dashboard in Elastic that assesses the delivery success rate for email originating from IPs having a PTR (i.e. reverse DNS) resolving to *.mailbaby.net, *.mailchannels.net, *.sendgrid.net, etc. A delivery success is simply defined as an SMTP connection that resulted in a message being delivered. By contrast, a delivery failure is an SMTP connection that did not result in a successful message delivery.
If we see a high rate of delivery failures, relatively speaking, it suggests that the sending network is trying to deliver email that can't be delivered. The hallmark of a reliable, scalable email delivery service is its ability to pre-filter messages so that undeliverable email is rejected before delivery is attempted, because having high rates of delivery failure harms your reputation.
The mail.baby chart was based on about 16,000 measured SMTP connections over a 30 day period.
This is disconcerting:
https://www.mail.baby/mailbaby-delivery-changes/
Words like “we commited”, “we will try”, “open ticket in case …”.
Was it sent to all baby mail clients?
Not one of those quotes can be found on the linked page.
Theoretically then, if I'm understanding that correctly, people like me could have contributed to exactly that. Here's what I mean:
If an email can't be delivered by my relays after several attempts, we relay to mail.baby who then would try several more times. If they couldn't, they would pass it to MailChannels who would then try a few more times and bounce it if they couldn't. However, what we identified was that almost every email that made it that far in the stack is an email that can't be delivered and should have been halted earlier.
It's hard to systematically know what emails can't be delivered 100% of the time. There are many grey areas where the evidence suggested it might eventually work, but in reality the recipient server was just broken.
So technically I could say we have extremely poor delivery rates through mail.baby and by extension MailChannels. But in doing so what I would actually be saying is that our relays are great, and we're always learning about what emails we should stop retrying to send. So the failure isn't baby or MC, or even ours as far as it relates to our ability to deliver, it's purely ours for retrying undeliverable email too many times. And it's not that big of a failure, doesn't hurt anyone to hammer at an SMTP server that isn't even online for a few hours. It's not like anyone was repeatedly retrying after a "no such recipient" response.
So wouldn't that actually suggest that mail.baby has great delivery, because what they sent to you was mostly undeliverable? Meaning what could be delivered, they delivered without needing you? And that anything else is really just a statement that they could've paid you less if they stopped trying sooner?
Also, as a side note, why are you sharing data about your recently former customer's delivery statistics? Did they authorize you to share that information, is it part of your policy that you might, or is this a retaliatory effort against a customer you burned? I'm all for it if they were abusive of course.
@jar,
Thank you for your insightful comment. You raise a good point about how the high failure rate of messages relayed from mail.baby to MailChannels could be interpreted as mail.baby successfully delivering most messages on their own.
However, I would argue that the assessment of email deliverability remains the same. If an email delivery service has a relatively high rate of delivery failures, as the data shows for mail.baby, it suggests that the service is not doing a great job of rejecting email messages that are likely undeliverable in the first place. This indicates that they may be doing a poor job of assessing the reputability of senders before attempting delivery.
Operating in this manner, by repeatedly attempting to deliver messages that have a low probability of successful delivery, will earn the sending service a relatively poorer reputation over time. This is because receiver systems are tuned to judge sending IPs negatively if they have a low ratio of delivered to attempted email.
So while mail.baby may be delivering many messages successfully on their own, the high percentage of undeliverable messages they are attempting to send is still likely to harm their sending reputation in the long run. A robust email delivery service should strive to reject probable spam and undeliverable messages early in the process to maintain the best possible reputation with receivers.
I appreciate you weighing in on this complex topic and sharing your perspective. Email deliverability is a nuanced issue and this kind of thoughtful discussion is valuable for the whole community.
I appreciate your concern for mail.baby's privacy. We never share information about customer data, nor do we even acknowledge that a customer is our customer without their consent.
The charts that I shared above are based on statistics about SMTP connections that we received from IP addresses whose reverse DNS (PTR) matches the pattern "*.mailbaby.net". The statistics for SendGrid, Mailgun, and Google were gathered in the same way by observing the SMTP connections hitting our inbound filtering service.
Good luck with that. I asked them few weeks ago, still to get a response.
With their $500/m minimum (as advertised on the site), its certainly not meant for different kind of customers.
Mail.baby is pretty amazing. They had email delivery issue few days ago but its resolved now. (Wish it was resolved even quicker) But what they offer for the price, you really can not ask for more.
Looks like it was a premature disclosure. They are not yet ready to discuss it.