Hi, Can any one offer advice about a problem I've been having with email for a few months now? I suspect it has something to do with increased security at host mx4.hotmail.com but I can not confirm this. The problem (in brief) I host a number of websites. Each of these has a "contacts" page where any one may send an email. The page contains the following fields: 1 a drop down box to select the recipient (e.g. secretary, chair, treasurer, events co-ordinator, etc.) 2 a text field for the sender's own email address 3 a free text field. This prevents the sender knowing the email address of the recipient and sends an email with: To: = the recipients real email address From: = the sender's own email address Subject: = "website contact" and the body containing the free text stripped of any HTML. All of the above works fine for all sender addresses and recipient addresses *except* when the sender is <sender>@yahoo.co.uk and the recipient is <recipient>@live.co.uk which results in a failed to deliver message which contains: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: <recipient>@live.co.uk SMTP error from remote mail server after end of data: host mx4.hotmail.com [65.55.37.120]: 550 5.7.0 (COL004-MC4F7) Unfortunately, messages from (212.23.1.5) on behalf of (yahoo.co.uk) could not be delivered due to domain owner policy restrictions. ------ This is a copy of the message, including all the headers. ------ Meanwhile a copy of the email sent at the same time to me as site administrator works fine and is delivered. 65.55.37.120 is microsoft 212.23.1.5 is Zen internet (my isp). obviously <sender> and <recipient> have replaced real email names. Any ideas what I need to change to make hotmail accept these emails again. Or do I just have to wait it out? Nev
On 2016-12-07 08:53, Nev Young wrote:
All of the above works fine for all sender addresses and recipient addresses *except* when the sender is <sender>@yahoo.co.uk and the recipient is <recipient>@live.co.uk
Hi Nev, I'm no expert in this field, so take this mail with a pinch of salt. You are attempting to send a mail from your server to live.co.uk, with a sender address yahoo.co.uk. On the receiving server this is indistinguishable from a spam delivery attempt. First, make sure your server is not listed at any RBL. If that is the case, address the underlying problem why you ended up in that list. The admin on live.co.uk is free to implement any spam fighting mechanism they feel fit, but chances are that they implement a strict SPF+DMARC policy. The SPF policy for yahoo.co.uk [1] is "v=spf1 redirect=_spf.mail.yahoo.com", which redirects to a [2] with policy "v=spf1 ptr:yahoo.com ptr:yahoo.net ?all". The DMARC policy for yahoo.co.uk is [3] "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;". To sum up, your mail server is not in the SPF mandated networks yahoo.com or yahoo.net, and DMARC tells the receiving host to reject mails if the SPF test fails. So that could be the reason why live.co.uk won't accept your mails. One way around this would be to send your mails with an envelope sender address using your domain. That is *not* the header From: address the user sees in his MUA, but it is the one that the MTAs use to send bounces to. SPF should validate the envelope sender address and not the From: header. This way the recipient of the mail still see the correct from address (the one from your web form) as the sender, but the receiving mail server will apply *your* SPF+DMAC policy if any, and not a 3rd party's one. If you can't set the sender address, then you could use a noreply@your-domain.tld in the From: header and set the Reply-To: header to help the recipient to respond to the right address. HTH, Thomas [1] http://mxtoolbox.com/SuperTool.aspx?action=spf%3ayahoo.co.uk [2] http://mxtoolbox.com/SuperTool.aspx?action=spf%3a_spf.mail.yahoo.com [3] http://mxtoolbox.com/SuperTool.aspx?action=dmarc%3ayahoo.co.uk
On 07/12/16 08:53, Nev Young wrote:
Hi, Can any one offer advice about a problem I've been having with email for a few months now? I suspect it has something to do with increased security at host mx4.hotmail.com but I can not confirm this.
[SNIP] On this subject, possibly unrelated, I've been having a lot of trouble with MS-hosted email services on my email filters and client servers. Often clients are unable to send email to them, or indeed to receive from them. I can't do much about the sending as once they've sent the email (via their ISP's SMTP servers), I have no visibility, but receiving is different. Many MS SMTP servers are bypassing the MX records, and attempting to deliver directly to the client's server. Of course this generates a 554 error (relay denied) and the email is dropped. I can't explain it or stop it, but it continues to happen. Cheers, Laurie. -- --------------------------------------------------------------------- Laurie Brown laurie@brownowl.com ---------------------------------------------------------------------
This looks like it might be due to Microsoft's servers enforcing Sender Policy Framekwork (SPF), where the recipient server checks with the originator domain to validate that the message came from an approved server. As you're relaying (via Zen), this check is failing as Zen is unlikely to be a valid originator of Yahoo emails. I used to have the same problems with my own email when I used to relay everything for my domain on to my ISP's mail server, and some - but by no means all - mail got bounced. See https://en.wikipedia.org/wiki/Sender_Policy_Framework Cheers, Simon On 07/12/16 08:53, Nev Young wrote:
Hi, Can any one offer advice about a problem I've been having with email for a few months now? I suspect it has something to do with increased security at host mx4.hotmail.com but I can not confirm this. The problem (in brief) I host a number of websites. Each of these has a "contacts" page where any one may send an email. The page contains the following fields: 1 a drop down box to select the recipient (e.g. secretary, chair, treasurer, events co-ordinator, etc.) 2 a text field for the sender's own email address 3 a free text field.
This prevents the sender knowing the email address of the recipient and sends an email with: To: = the recipients real email address From: = the sender's own email address Subject: = "website contact" and the body containing the free text stripped of any HTML.
All of the above works fine for all sender addresses and recipient addresses *except* when the sender is <sender>@yahoo.co.uk and the recipient is <recipient>@live.co.uk which results in a failed to deliver message which contains: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: <recipient>@live.co.uk SMTP error from remote mail server after end of data: host mx4.hotmail.com [65.55.37.120]: 550 5.7.0 (COL004-MC4F7) Unfortunately, messages from (212.23.1.5) on behalf of (yahoo.co.uk) could not be delivered due to domain owner policy restrictions. ------ This is a copy of the message, including all the headers. ------
Meanwhile a copy of the email sent at the same time to me as site administrator works fine and is delivered.
65.55.37.120 is microsoft 212.23.1.5 is Zen internet (my isp). obviously <sender> and <recipient> have replaced real email names.
Any ideas what I need to change to make hotmail accept these emails again. Or do I just have to wait it out?
Nev
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ https://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Nev, I'm sure someone more knowledgeable can jump in to correct me where I'm wrong, but here's my off-the-cuff reply - without doing any fact-checking. ;) I think you're coming across a problem that is basically because your concept of a webserver sending an email on behalf of someone is no longer considered a good practice - it's basically doing the same thing as a spammer would do. Send an email and then just change the From: header to be from the address that has been typed in on your webpage. Many spammers have used this technique (spoofing the From: address to be from a valid user) over the years to peddle their wares, and so technologies like SPF have been introduced to stop emails being accepted if they have not been sent by the SMTP server associated with the sender's domain. This means that for the email to be sent from Yahoo! to be accepted, it should be sent from Yahoo!'s email servers - and not your ISPs. There is no work around for this new security tightening - you are sending emails on behalf of another email server, from your webserver ... and that is now something that is frowned upon. My experience is that the webpage your describing is somewhat of a pain for end-users anyway. It is frustrating to go to a page like that, send an email and then have no idea whether it has actually been received by the end-recipient. Many times those scripts break because of problems at the hoster, but noone is aware for months and so anyone trying to use the form is utterly stuck, if there are no other contact details on the site. Might I suggest the simpler approach of removing the whole thing and instead setting up some email forwarders so that secretary@ chair@ treasurer@ and events@example.org forward through to the appropriate person. This will achieve the same thing you're currently doing, with no maintenance on the website and immediate feedback to the end-user who will get a bounce response if the email cannot be delivered for whatever reason. If you're worried about someone harvesting the forwarding email addresses if you put them directly on the website, you can always obfuscate them using a site like this: http://www.fingerlakesbmw.org/main/flobfuscate.php but, tbh, it's virtually impossible to hide addresses for too long, so people would be far better investing time in setting up a decent spam filter. HTH, Peter. On 7 December 2016 at 08:53, Nev Young <alug@nevilley.org.uk> wrote:
Hi, Can any one offer advice about a problem I've been having with email for a few months now? I suspect it has something to do with increased security at host mx4.hotmail.com but I can not confirm this. The problem (in brief) I host a number of websites. Each of these has a "contacts" page where any one may send an email. The page contains the following fields: 1 a drop down box to select the recipient (e.g. secretary, chair, treasurer, events co-ordinator, etc.) 2 a text field for the sender's own email address 3 a free text field.
This prevents the sender knowing the email address of the recipient and sends an email with: To: = the recipients real email address From: = the sender's own email address Subject: = "website contact" and the body containing the free text stripped of any HTML.
All of the above works fine for all sender addresses and recipient addresses *except* when the sender is <sender>@yahoo.co.uk and the recipient is <recipient>@live.co.uk which results in a failed to deliver message which contains: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: <recipient>@live.co.uk SMTP error from remote mail server after end of data: host mx4.hotmail.com [65.55.37.120]: 550 5.7.0 (COL004-MC4F7) Unfortunately, messages from (212.23.1.5) on behalf of (yahoo.co.uk) could not be delivered due to domain owner policy restrictions. ------ This is a copy of the message, including all the headers. ------
Meanwhile a copy of the email sent at the same time to me as site administrator works fine and is delivered.
65.55.37.120 is microsoft 212.23.1.5 is Zen internet (my isp). obviously <sender> and <recipient> have replaced real email names.
Any ideas what I need to change to make hotmail accept these emails again. Or do I just have to wait it out?
Nev
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ https://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
participants (5)
-
Laurie Brown -
Nev Young -
samwise -
Simon Ransome -
Thomas Pircher