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
Absolutely. It's the kind of thing you'll never regret learning if you're into system administration even as a hobby.
Thanks for the encouragement, doing the same with hosting my own NS, you learn so much from it. Thanks for providing such a awesome service as well
I think the disconnect here is that MXRBL is used in an operational context where email is expected from a properly configured mail server. His service is not a mail server but rather a server that hosts his website and he has basically sendmail sending emails to him and his clients directly who are hosted on MXRoute.
This server is not a mail server. Instead, his course of action should be to configure the app or sendmail to use SMTP to use an email relay (can be an account on MXRoute) to send their email. Noone should unblock your single webserver IP (that's not a mail server) just so you can send emails "incorrectly". It also doesn't make sense to ask an operational black list used by many other vendors to do this.
Basically, @jar was checking to see if the server the user had was a proper mail server. Since it wasn't (it basically did not pass the sniff test and didn't have the bare minimum configuration set for even basic mail delivery), he didn't approve the user's request.
I mean from what I read, he didn't even set PTR record for the IP... That's like email 101. There's no reason to unblock an IP like that.
Just to be clear then, your service should not be considered one that allows people to send automated, transactional email.
This seems like a something that most people would expect and is a common and expected use case, even for services that offer fully hosted email.
Completely false, you're way out of your depth on this one. But you're determined to have an opinion on it anyway, so have at it.
Is this not what they have done, I was under the impression that the problem was that MXroute has blocked a bunch of IP addresses from their SMTP relay servers because they were commonly used as spam.
So, you expect that everyone who uses your service as a SMTP relay server must also host their own email server as well?
What, Jarland doesn't care if you send automated or transactional email via Mxroute this issue is just a user moaning Jarland didn't whitelist his sending IP, a IP at from a spammy isp and with no PTR , I know ptr isn't technically a requirement for outgoing mail but it's good practise and ip sending mail without it are lazy admins.
No. MXRoute has blocked random emails from IPs that are from either spam networks or were not authenticated. Instead, the guy basically had sendmail send an email with default configurations expecting it to hit his inbox hosted on MXRoute. MXRoute's spam filter did not accept the email and then OP got pissed.
Instead, what he should have done was hae the server authenticate with MXRoute through SMTP and send an email that way.
Basically, OP sent an email to himself as an unauthenticated user with an IP that was blacklisted with no configuration as a mail server.
You use SMTP or set up an email server the right way then it's fine. You don't even configure the PTR record and yet demand getting off the blacklist... yeah that's not going to fly.
I also wondering why no one still didn't mention here the main rules I violated today
The are also a lot of ideas how to setup smtp.
The truth is that in case you set up your own mailserver to send-relay in 80% cases you don't need mxroute to send mail at all if you are not a polite spammer
But may be you still need to receive mail
Per OP's post:
They say they're sending from {blacklisted server} => mxroute => gmail.
Again, the usecase that is being discussed here is one where someone has a server with a really horrible IP rep, they want to send email from that server and they purchased a service that they thought would allow them to do that. This is a really common use for purchasing an email service: simply being able to send emails from IPs that dont have a good reputation.
You're on an entirely different topic. These are two different scenarios:
Your mail server sends an email to my mail server. If your IP is blacklisted, I block it.
Your web server connects to my mail server to authenticate over SMTP with an email account you created on my service, IP blacklisting is suddenly irrelevant. Send what you want, it goes through fine.
I can either field complaints about people receiving too much spam or complaints about people wanting to do the #1 option above without any effort on their part to correctly set up a mail server. To field complaints about both would be more of a fantasy than a Disney movie.
Oh, so then yes we are on the same page here.
This is really all I wanted to know in terms of what is acceptable and what isn't.
I believe that any sane person who wants to actually send email would do this. I assumed that what OP said in his original post was that he had tried to do this, and it had refused to allow them to send emails.
Should I also authenticate on each server where i send e-mails ?
Or mxroute is so great that i need to do this only there ?
Be attantive. I wrote i was sending my server => mxroute => my gmail (via imap , pop3 from accounts on mxroute)
Yes, obviously.
Are you being a smartass when you're the one clearly in the wrong? You've been told by multiple people in this thread what to do to fix it and apparently adding authentication is too much for you? GTFO
What? You're confusing AF. That's irrelevant to this thread. You don't have a clue what's going on.
It sounds like you don't really know how mxroute works.
There's two parts to it - the incoming mailbox, where the mail server that receives mail at mxroute makes sure that the sending mail server looks legitimate and non-spammy. This is what's causing the problem, because your mail server looks non-legitimate and very spammy. However, as an incoming mail system, these checks are exactly what's needed to get rid of a lot of spam.
The second part is to use mxroute for outgoing mail, for which you use the authenticated system. It doesn't matter what the destination is - mxroute, gmail, .gov, whatever. Authenticate your mail, and it'll be sent via a legitimate looking server, and if the ultimate destination is another mxroute customer, it'll end up there because it's being set via mxroute's clean IP range.
You're not supposed to send outgoing mail from an mxroute domain from your own mail server, because chances are high it'll be marked as spam. Unless you're authenticating to mxroute, it has no way of knowing that your server is a customer server or some spam factory. As your IP is from a known-spammy network, it's assumed to be spam. This is as-designed.
But it was pretty clear from the get-go that the OP hadn't tried to do this
One would need to go back to the beginning of the millennium to try to do what the OP tried to do and to expect that it would generally work
I really respect your opinion.It is very constructive in this context and helps to understand the requirements for the target audience of the service that is being discussed here
Maybe you have some other more important advice ?
I'm not trying to bandwagon and rather I think we can use this as an opportunity for everyone to get more familiar with the nuances of emails. So please bare with me.
Ideally, yes. This is exactly how it should be done. With MXRoute or any other vendor in fact. You can even do it with Mailgun, AWS, etc. I have an example outlined below on how to resolve this.
My interpretation of this was blacklisted server sent the "TO" field in their email to a MXRoute email address which then forwards to Gmail (or has gmail poll it using POP3). Jarland has historically had a problem with this (and probably still) as it's a really common way people have been using MXRoute but also meant that GMail sometimes drops emails from other vendors without telling anyone (silently dropping) and then Gmail blames third party mail vendors on their infrastructure.
That's a whole nother conversation on it's own, but my interpretation of how OP has configured their pipeline is very similar to this example.
Example Problem:
Blacklisted Server -(Sendmail w/o Auth)-> MXRoute -(Mail Forwarding Rule)-> GMail
I configure LibreNMS to alert me when a server is down. It's sending directly from my server (using sendmail with default configurations) to my address at [email protected], which is hosted on MXRoute. On MXRoute, my email is forwarded to my gmail. I don't receive emails to [email protected] because it turns out my IP is blocked by MXRBL and turns out I didn't setup PTR record for my LIbreNMS server IP.
Example Resolution:
Blacklisted Server -(Sendmail w/ SMTP Auth)-> MXRoute -(POP3 from GMail)-> GMail
I can configure LibreNMS to use SMTP Directly: https://docs.librenms.org/Support/Configuration/#email-configuration
Or I can configure Sendmail to use SMTP relay: https://www.snel.com/support/smtp-relay-with-sendmail/
This is my understanding of the situation and from what I can tell (and how @dusst is complaining about "I have to configure this for every server? What a hassle.") this is exactly how it played out.
Pls tell me exactly what I have to try ?
It is not clear what changed in SMTP from the beginning of the millennium
If you study some of the posts in this thread, you'll get a pretty good idea of what you have to try
It's not SMTP that has changed since the beginning of the millennium, but rather it's the fight against spam that has changed and all that this entails (rDNS, IP reputation, etc.)
that's all right. its important and possible to make sending and relaying more secure.
but it's not about a topic. and again there was no single word about relaying. and not about ptr. and my scheme worked well with mxroute and my other servers for 1.5 years
the topic was very simple
ip-range was/is incorrectly blocked . and how the situation continued
If true, then you were lucky during that time, but your luck has come to an end
Well that's the thing.
IP range (in my opinion) was correctly blocked. While the fundamental mail protocol has not changed over the last various years, the way mail is handled and that landscape has continued to change over time. GMail, Outlook, MXRoute, and others have all had to play a game of "which one's fucked today" to give that consistent stable experience. From my understanding, it was your implementation that was incorrect to begin with and maybe a recent server update or something has tightened that loophole.
For smaller-volume players, it doesn't matter as much and it's not that big of a problem... well unless you're trying to reach gmail in which case after like 20 emails or so you'll probably run into problems. MXRoute is not a small-volume player within the mail space. Yeah they're smaller than Microsoft Outlook, GMail, or AWS, but compared to your and my VPS running small-batch alert emails (or internal emails) it's a bit different. MXRoute plays within this landscape and operating inside it is always a bit more work than you'd imagine. But with that comes reliability that our email will always hit the inbox we need to get to at an affordable rate.
Everyone could have resolved this better. But... Ehhh... Situation is what it is. At the end of the day, your configuration was incorrect (not pointing fingers, just... that's the fact). And the value Jarland brings with MXRoute is pretty much bar none.
The big mistake that @dusst made is basically about unrealistic expectations for what $XX was going to buy him, and I mean this respectfully to all parties that think they are buying a golden throne for a LET BF special.
@dusst assumed that for a few bucks, @jar was going to bend over backwards and accommodate his request for allowing an IP which in @jar's extensive experience would have low trust and high turnover, which ultimately would negatively impact the quality of his service for other MXRoute customers, among other issues. Not to mention @jar is literally following best practices on the matter, so it would be disappointing if he DID allow the exception. Basically, @jar is just maintaining his product's reputation for deliverability and stability, and promptly giving the proper methods to access his services.
When @dusst didn't follow directions and do the work needed to come into reasonable compliance, he publicly complained, thinking that his moral outrage at this injustice would evoke sympathy from the LET community.
Frankly, it's amazing what you DO get for that few dollars, and that is a huge investment into MXRoute's reputation for deliverability, which few -- if any -- services can rival for that kind of price. Come on.
Now say what you want about @jar's brutal honesty and in his occasionally "blunt" word choice for customer service, but at least he's consistent, up front, AND he gave a full refund when he didn't need to. That's also classy.
Now I do wish he would implement a couple of features (like LUKS, hint hint!) but for a few bucks am I going to be whining and complaining about it? No way. (Although I would willingly pay more for LUKS-enabled option at MXRoute.)
Anyway, this is a great example of unrealistic expectations, and TBH, @jar's handling of this situation increases confidence in his services, not reduces it.
if i'm "lucky" and greencloud and me hit the x.x.0.0/16 5-years old blacklisted network. Why not to blacklist the whole 0.0.0.0/0 network and to remove that mxrbl list at all ?
And why google with gmail still didn't do the same )
LOL Oh boy you want to compare this to Google and Gmail's email rules?
If you're low volume enough then just do straight gmail. But sooner or later Google will also block your emails without telling you.
"What works now, is not a guarantee what will work later" - I don't know... someone
gmail is pretty bad at this. It works initially... until it doesn't. Then they're a bitch to deal with.
... he didn't have to read the documentation.
This sounds faceitous, but I mean it. He thinks he's been sending mail out through mxroute all this time, but he hasn't. He was sending mail directly to the receiving mail server all this time without authenticating it.
His mail got rejected because it now his IP range has been backlisted due to spam. That's what's supposed to happen. If he'd sent his mail properly in the first place, it'd still be getting delivered.
yes. for sure i'm not a girl )
but the is no answer for my question
so why not to advice to @jar to "blacklist" the whole web to keep the time spent for administration of "blacklist" for girls (and children) ?
if the rules are the same for all it's more clear for all. or not ?
@dusst
How big a hole do you want to dig for yourself?
Maybe take a break and try to learn from this experience?
Oh boy is an idiom: https://en.wiktionary.org/wiki/oh_boy I wasn't calling you a boy. It's basically saying "there's a lot here to try and answer that question so I'm not going to."
So... Look. Mxroute is not blacklisting the whole web. My interpretation is that you have a misunderstanding of how this works and are understanding this incorrectly.
The end conclusion here is that you, as the server operator, made a mistake and misconfigured your server. This is to no fault of MXRoute or MXRBL. This is not a @jar problem. This is your fault. That's ok though, you can learn how to do it better. We have outlined here how you can do it better. But right now, you're just plain wrong.