E-Mail changes and home server

[daemon]

Hi,

I am trying to make sense of VM's latest communication relating to changes in e-mail security.

As I see it, if you spoof your From address to anything other than your @ntlworld.com, @blueyonder.co.uk or @virginmedia.com address then you need to register the spoofed From address with VM. I got that!

Additionaly, you now need to enable SMTP Auth for sending mail via VM's outgoing mail servers i.e. your mail client does a login before sending emails via VM.

Now, I run a home network (and mail server) which supports my own domain with multiple (and many) e-mail addresses. Until now I was just forwarding my e-mail through smtp.ntlworld.com as my smarthost without SMTP Auth. Will these new changes prevent me from doing this in future?

If it does, the timing is good because I'm getting a lot of calls from Talk-Talk and this might be what's needed to push me in their direction for broadband and telephone services.

Regards,
Neil Darlow

[BenMcr]

Originally Posted by daemon

Will these new changes prevent me from doing this in future?

Yes it will

[daemon]

Hi,

Do you, or anyone here, know how the SMTP Auth works?

Would it be possible to use e.g. my login credentials to authenticate for all e-mail sent through VM's outgoing server - or is it strictly a one-to-one login/e-mail address configuration?

I am trying to assess whether these changes are going to be a show-stopper for me.

Regards,
Neil Darlow

[BenMcr]

You can authenticate for as many times as you like - the issue comes with that unless each 'From' address is registered within the webmail service it get's overwritten with the VM address you are using to log onto the SMTP server with

[daemon]

OK then it's a show-stopper. Here ends 10 years as a NTL/VirginMedia customer.

This shows the effects that arbitrary changes to an existing system can have - in financial terms that's a £70 per month loss to VM.

Regards,
Neil Darlow

[BenMcr]

To be fair if you have a domain, you should really be channeling any emails through an smtp server associated with that domain - it's what I do

It means you aren't tied to a specific ISP or any changes they then make to their service

As SPAM levels increase you'll find that more and more ISPs do what Virgin have - I am suprised that TalkTalk still allow their SMTP server to be an open relay on their network

[daemon]

Originally Posted by BenMcr

To be fair if you have a domain, you should really be channeling any emails through an smtp server associated with that domain - it's what I do

It means you aren't tied to a specific ISP or any changes they then make to their service

As SPAM levels increase you'll find that more and more ISPs do what Virgin have - I am suprised that TalkTalk still allow their SMTP server to be an open relay on their network

I totally agree. The problem is that many organisations reject mail from IPs which are classed as "residential". Sending mail directly from my SMTP server (on the VM network) is problematic - which is why I use VM's server as smarthost.

I'm not aware that Talk-Talk operate an open relay, they employ SMTP Auth which, in itself, is not a problem and I can accommodate that in my server configuration.

What is a problem, as you highlighted, is having to register all your From addresses to prevent them being reset to the login address.

Another problem is the requirement to validate these registered addresses. How can you validate outgoing-only addresses like MAILER-DAEMON@domain.com?

This goes beyond Spam reduction. In essence, VirginMedia are saying we now only accept outgoing e-mail from Mail Clients. Those of us who run our own mailservers are being denied a facility we have enjoyed for over 10 years.

This is all the more galling because, as someone who knows how to administer mail services securely, I am being penalised by measures that have been introduced for those who don't have a clue.

Regards,
Neil Darlow

Regards,
Neil Darlow

[Peter_]

It is because we are using the Googlemail platform and this is how they require it to work.