When did MWEB start relaying all mail through their servers?

@Mweb: The zombie problem is huge - I am busy dealing with it on a number of networks. Redirecting traffic transparently is not the way to solve this. I've seen this 'in the wild' already and it is in fact worse than an outright block of port 25. It breaks SMTP badly and causes many half failures that are very difficult for users to identify or solve.

The current best solution is dynamic blocking of port 25 based on automated handling of abuse complaints and other metrics. This is not trivial to implement.

You cannot do on-the-fly redirection to a different server since the relayed mail will now originate from the wrong IP and SMTP AUTH is also now broken. If you would like a solution to this little problem then you are welcome to PM me to discuss. :)
 
ambo said:
You cannot do on-the-fly redirection to a different server since the relayed mail will now originate from the wrong IP and SMTP AUTH is also now broken. If you would like a solution to this little problem then you are welcome to PM me to discuss. :)
Click to expand...

Hence why the solution is to use SSL SMTP. 99.99% of people using mweb wouldn't be using external SMTP services anyhow and those who do generally have the knowledge to be able to implement SSL SMTP to their relay server.

What MWEB is doing is correct and it should have been done years ago by every ISP.
 
7th day adventist church said:
What MWEB is doing is correct and it should have been done years ago by every ISP.
Click to expand...
Are you smoking your socks? Blocking port 25 is a common and fairly successful solution to this problem. Redirecting traffic to another IP is just wrong in so many ways.
 
MWEB Operations said:
Hi Gatecrasher

You can still use the secure submission port 587 to communicate directly with any off network smtp server. This should work on any RFC compliant smtp server - you could also enable authentication when using those servers if it is supported.
Click to expand...

I couldn't do it via my web hosting server, since they don't provide a secure email server (although the server does require authentication). So I changed my smtp server to smtp.gmail.com on port 587 with TLS. It works fine. I can send mail. The only problem (but a biggie) is that it shows my mail coming from my gmail account rather than my website's domain (Outlook account), which is what I need. Any solution to this?



EDIT: Problem solved by changing the default "send mail as" account in the Gmail settings. Voila!
 
Last edited:
ambo said:
@Mweb: The zombie problem is huge - I am busy dealing with it on a number of networks. Redirecting traffic transparently is not the way to solve this. I've seen this 'in the wild' already and it is in fact worse than an outright block of port 25. It breaks SMTP badly and causes many half failures that are very difficult for users to identify or solve.

The current best solution is dynamic blocking of port 25 based on automated handling of abuse complaints and other metrics. This is not trivial to implement.

You cannot do on-the-fly redirection to a different server since the relayed mail will now originate from the wrong IP and SMTP AUTH is also now broken. If you would like a solution to this little problem then you are welcome to PM me to discuss. :)
Click to expand...

I agree, blocking port 25 outright based on the number of traffic that goes through that port from a specific user is best, not relaying it through a different server. They can just send a letter to the effect that the port was blocked due to abuse and that they should contact support to help them get rid of the virus or what not.
 
AcidRaZor said:
The only inconvenience was not knowing about the possible change. I like to be informed of things like this so that I don't try and debug/call my data center and log tickets to support which wasn't necessary. Luckily I've been on the internet long enough to know when something like this happens. Please NB my reply to Astroturf (below) so that you could get an idea of the impact this may cause for people who know WTF they're doing when it comes to email/spam/hosting.



It's not a question of receiving virus attacks via e-mail as much as your address being used to SPOOF a "valid" email address sending e-mail virus out into the internet. The way MWEB implements this relay requires you to add their mail server as a valid mail server in your SPF records in your DNS settings. Without prior notification of these changes, the SPF settings on your DNS will automatically disqualify any outbound e-mail you send out legitimately since the outgoing SMTP is not your own anymore. This causes quite a bit of frustration, I promise you. However, if notified, it's quite easy to change the SPF records in the DNS to allow for this.

The reason for SPF records is to tell other mail servers not to accept email from anywhere else except a specific email server (or array of email servers). This means that your mom won't get an email spoofed by someone else to make it look like you sent her the virus. The administrators at MWEB (at the NOC) should know this.



Port 587 is safe to use in any application, any mail server that hasn't been setup with that port including 25 for legitimate outbound email's does not comply with RFC standards, and not everyone can afford SSL so port 465 is usually out of the question. Thanks for highlighting my original question. and for MWEB to respond on this.

*edit* I just hope MWEB doesn't start intercepting 587 as well, else I'd have to look for a different ISP
Click to expand...

I agree that they should have warned clients. Having users down your neck then having to work out why because a simple email was not sent out is a huge pain in the backside.
 
AcidRaZor said:
I agree, blocking port 25 outright based on the number of traffic that goes through that port from a specific user is best, not relaying it through a different server. They can just send a letter to the effect that the port was blocked due to abuse and that they should contact support to help them get rid of the virus or what not.
Click to expand...

We've actually had that solution in place for the last month or two - excessive traffic on port 25 is being blocked and will result in you being served a landing page in your browser (error 607) the next time you launch it indicating that you have been sending out large amounts of traffic and that you might have a virus, etc etc. Unfortunately this is simply not proving to be an effective measure and honey pots are still being hit on a regular basis which is causing a real headache for us.

The two choices left are to block port 25 outright to anything except our relays, or to go with this option which is a silent redirect. Ultimately either solution is going to generate some support traffic, but this really is a question of the lesser of two evils as I'm sure that you can appreciate that we'd prefer to be in a position where we didn't have to do either of these.

Just to clarify again my response to AcidRazor those affected yesterday were only a small test block of IPs. We will be sending a communication to the entire customer base, hopefully today, informing them of this and we will proceed with full scale implementation after that.

If anyone is having problems sending to an external relay which does not recognize the more secure smtp submission port (587) which we are allowing off net, please provide the details to MWEB Operations, or you can mail it to [email protected] and we'll look at putting an exception in place for you.
 
Last edited:
Will@MWEB said:
If anyone is having problems sending to an external relay on 587, please provide the details to MWEB Operations, or you can mail it to [email protected] and we'll look at putting an exception in place for you.
Click to expand...

Wait, does this imply that you're actually treating port 587 the same as port 25?
Thats just not on...

Sure, blocking 25 makes sense, but 587 is the mail submission port, you should NOT be messing with that.
 
daffy said:
Wait, does this imply that you're actually treating port 587 the same as port 25?
Thats just not on...

Sure, blocking 25 makes sense, but 587 is the mail submission port, you should NOT be messing with that.
Click to expand...

Which is precisely why we aren't blocking it - but not all relays were made equal and should you find yourself in a position where you are trying to reach a server that will not accept traffic on Port 587 then we will see what can be done to accommodate you.
 
Will@MWEB said:
Which is precisely why we aren't blocking it - but not all relays were made equal and should you find yourself in a position where you are trying to reach a server that will not accept traffic on Port 587 then we will see what can be done to accommodate you.
Click to expand...

I cannot connect to my outbound smtp server on 25 or 587...

SMTP address is smtp.phuck.co.za and no, I'm not joking, it's my domain

The fact that MWeb redirects this traffic is BS. I'm a regular user not abuser and probably send less than 100 email per month.

And to think I always thought MWeb was brilliant...
 
Last edited:
JUGGY said:
I cannot connect to my outbound smtp server on 25 or 587...

SMTP address is smtp.phuck.co.za and no, I'm not joking, it's my domain

The fact that MWeb redirects this traffic is BS. I'm a regular user not abuser and probably send less than 100 email per month.

And to think I always thought MWeb was brilliant...
Click to expand...

Hi Mark

Thanks for your feedback. The solution we have put in place is to protect the integrity of our network and thus the experience of all of our customers from viruses and spam. In terms of your issue with mail sending please could you contact the Tech support at your domain host (Texo) and ask them to have a look at whether sending on port 587, or perhaps SSL over port 465 is supported. These are RFC compliant configurations so this should be possible for them. If you are still having a problem after this please let us know and we'll see if there is an alternative solution for you.

I would also ask please that you try to keep your tone in these discussions polite and respectful going forward, it really makes things unpleasant for everyone when the conversation descends into namecalling and personal attacks.

Thanks
Will
 
JUGGY said:
I cannot connect to my outbound smtp server on 25 or 587...

SMTP address is smtp.phuck.co.za and no, I'm not joking, it's my domain

The fact that MWeb redirects this traffic is BS. I'm a regular user not abuser and probably send less than 100 email per month.

And to think I always thought MWeb was brilliant...
Click to expand...


Your server doesn't listen on port 587. You need to get your provider to configure this. Why they don't already, is a question you need to ask them...
 
daffy said:
Your server doesn't listen on port 587. You need to get your provider to configure this. Why they don't already, is a question you need to ask them...
Click to expand...

How about this, MWeb gives me the service I pay for??? Port 25 is a standard port, I shoudn't need to re-invent the wheel to send a simple email.
 
Last edited:
Will@MWEB said:
I would also ask please that you try to keep your tone in these discussions polite and respectful going forward, it really makes things unpleasant for everyone when the conversation descends into namecalling and personal attacks.

Thanks
Will
Click to expand...

I'm sorry, what part of my tone didn't you like??? Could it have cropped up around the time you changed your service without notifying your customers?

When did I raise a personal attack against you or MWeb??? If you're referring to something I said to someone else then my advice to you is butt out and mind your own business. Rather fix my issue and look at customer service. Why inconvenience your customers on port 25??? Ever heard of bayesian filters? That would be better than the knee jerk reaction of simply banning your users from utilising port 25 with ZERO notification...

Polite an respectful? Wow is all I can say, are we in a relationship that I didn't know about? How about respect my hard earned money I pay for a service that has suddenly changed without notification?
 
Last edited:
Yea this started happening to me to , the application iam busy developing sends mail out quite alot , i kept on getting that ladding page. i just started using there smtp :P problem solved , all my mail is going through quick quick.
 
@Mark the solution we are in the process of implementing is not outright blocking of port 25, its a redirect to ensure that the traffic passes through our relays so that normal virus and spam filtering can take place.

Port 25 mail is in all honesty a vulnerable dinosaur and many isps are being forced down a route similar to this to combat the fallout that occurs from zombie traffic which is sent directly from infected PC's on port 25 causing listings on our IP ranges.

It's actually reached the point where some blacklisting providers are beginning to insist that ISPs look at putting solutions like this in place.

This also puts us in a better position to work with our customers who have become infected and notify them of the situation.

We have actually only implemented this for a small block of IPs as a test to understand the full impact and will be sending out a notification early next week to our entire client base before we roll this out full scale. This was made mention of earlier in the thread, please accept our apologies for the lack of notification.

Please let us know if you were successful in getting Texo to accept the traffic on port 587, they seem to offer the full range of services so I'm sure they should be able to accommodate this.

@Grim The landing page you're referring to is the one that crops up when excessive "offnet" smtp activity is detected, I'm guessing this would have been triggered when you were testing your application, sending through our relays would be the best solution for you to use there, thanks for your patience and understanding :)
 
I have got it working but as I have stated I feel it unfair to re-route my port 25 traffic. I am re-considering my future as client of MWebs based on this.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X