On Sun, 5 Feb 2012 18:00:39 +0000, Tommy Traddles wrote: > > >Have a weird situation where a client externally outsources an application which generates emails and sends PDFs to their own internal domain. For some reason the party that is hired to develop and maintain that application is set up to send the emails, has coded it so that the emails are sent out spoofing the personal email accounts of some of the clients staff (including Microsoft free email addresses from live.com and hotmail.com). This incomprehensible arrangement worked for a year or so, but recently Forefront has started picking up that the headers of these emails claiming to be from 'hotmail.com' etc. are originating from a source different to the MX records of these domains, and blocks them as spoofed. Now the client is adamant that this spoofing application cannot be modified to send out using a domain purchased for this purpose, but are demanding a solution. Since they don't own the e-mail system that uses hotmail.com as the domain they really are in no position to demand anything except the scorn of e-mail admins everywhere. If the domain owner chooses to publish SPF records that declare the IP addresses that are authorized to send e-mail bearing that domain then that's the way it is. Too bad for the client, and the company that wrote the software should be ashamed. >Aside from whitelisting free email domains (or their servers' IP address ranges) on Forefront (obviously a huge >security risk), I don't know how to allow the mail to flow again. Whitelist the IP address of the server that spoofs the hotmail.com domain. >I was thinking if we can purchase another domain, we can possibly get the application to forward to email addresses created for the users from this new domain, and then get mail sent to this domain forwarded on to the client automatically. Does anyone have any thoughts on how I might do this? Or perhaps offer an alternative solution? Send the messages using the domain that the client owns. They can publish SPF data (or not) for their own domain. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Have a weird situation where a client externally outsources an application which generates emails and sends PDFs to their own internal domain. For some reason the party that is hired to develop and maintain that application is set up to send the emails, has coded it so that the emails are sent out spoofing the personal email accounts of some of the clients staff (including Microsoft free email addresses from live.com and hotmail.com). This incomprehensible arrangement worked for a year or so, but recently Forefront has started picking up that the headers of these emails claiming to be from 'hotmail.com' etc. are originating from a source different to the MX records of these domains, and blocks them as spoofed. Now the client is adamant that this spoofing application cannot be modified to send out using a domain purchased for this purpose, but are demanding a solution. Aside from whitelisting free email domains (or their servers' IP address ranges) on Forefront (obviously a huge security risk), I don't know how to allow the mail to flow again. I was thinking if we can purchase another domain, we can possibly get the application to forward to email addresses created for the users from this new domain, and then get mail sent to this domain forwarded on to the client automatically. Does anyone have any thoughts on how I might do this? Or perhaps offer an alternative solution? Many thanks.

On Sun, 5 Feb 2012 18:00:39 +0000, Tommy Traddles wrote: > > >Have a weird situation where a client externally outsources an application which generates emails and sends PDFs to their own internal domain. For some reason the party that is hired to develop and maintain that application is set up to send the emails, has coded it so that the emails are sent out spoofing the personal email accounts of some of the clients staff (including Microsoft free email addresses from live.com and hotmail.com). This incomprehensible arrangement worked for a year or so, but recently Forefront has started picking up that the headers of these emails claiming to be from 'hotmail.com' etc. are originating from a source different to the MX records of these domains, and blocks them as spoofed. Now the client is adamant that this spoofing application cannot be modified to send out using a domain purchased for this purpose, but are demanding a solution. Since they don't own the e-mail system that uses hotmail.com as the domain they really are in no position to demand anything except the scorn of e-mail admins everywhere. If the domain owner chooses to publish SPF records that declare the IP addresses that are authorized to send e-mail bearing that domain then that's the way it is. Too bad for the client, and the company that wrote the software should be ashamed. >Aside from whitelisting free email domains (or their servers' IP address ranges) on Forefront (obviously a huge >security risk), I don't know how to allow the mail to flow again. Whitelist the IP address of the server that spoofs the hotmail.com domain. >I was thinking if we can purchase another domain, we can possibly get the application to forward to email addresses created for the users from this new domain, and then get mail sent to this domain forwarded on to the client automatically. Does anyone have any thoughts on how I might do this? Or perhaps offer an alternative solution? Send the messages using the domain that the client owns. They can publish SPF data (or not) for their own domain. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP