You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Joe Acquisto-j4 <jo...@j4computers.com> on 2015/10/22 16:34:46 UTC
SOT - Fowarding mail to new service, keeping same MX, pitfalls
This may not be the right place to discuss this, as it is a generic anti SPAM query, but please indulge and point me to where answers might be found. Or, just answer if you feel inclined. After this mornings SPF discussion . . . well, I'll ask anyway.
An organization I know of is moving to o365 from their own mail system. For a variety of reasons, the migration cannot be completely resolved "day one". Thus, we concocted a scheme of keeping MX as is, and having the current system simply relay messages to o365 and have users start using o365 right away.
Everyone thought this a great idea, solving several issues, until, suddenly, last evening, I realized that we would be sending email that might appear "spoofed". That is, from IP's that are not published as "ours".
I've not run this by any one else yet, hoping to either allay my concerns, or raise the alarm and have some suggested solutions, by asking a well versed group.
joe a.
Re: SOT - Fowarding mail to new service, keeping same MX, pitfalls
Posted by David Jones <dj...@ena.com>.
>________________________________________
>From: Joe Acquisto-j4 <jo...@j4computers.com>
>Sent: Thursday, October 22, 2015 9:34 AM
>To: users@spamassassin.apache.org
>Subject: SOT - Fowarding mail to new service, keeping same MX, pitfalls
>This may not be the right place to discuss this, as it is a generic anti SPAM query, but
>please indulge and point me to where answers might be found. Or, just answer if
>you feel inclined. After this mornings SPF discussion . . . well, I'll ask anyway.
>An organization I know of is moving to o365 from their own mail system. For a
>variety of reasons, the migration cannot be completely resolved "day one". Thus,
>we concocted a scheme of keeping MX as is, and having the current system simply
>relay messages to o365 and have users start using o365 right away.
>Everyone thought this a great idea, solving several issues, until, suddenly, last
>evening, I realized that we would be sending email that might appear "spoofed".
>That is, from IP's that are not published as "ours".
https://community.office365.com/en-us/w/exchange/simple-domain-sharing-for-smtp-email-addresses
>I've not run this by any one else yet, hoping to either allay my concerns, or raise
>the alarm and have some suggested solutions, by asking a well versed group.
>joe a.
Re: SOT - Fowarding mail to new service, keeping same MX, pitfalls
Posted by Axb <ax...@gmail.com>.
On 10/22/2015 04:34 PM, Joe Acquisto-j4 wrote:
> This may not be the right place to discuss this, as it is a generic
> anti SPAM query, but please indulge and point me to where answers
> might be found. Or, just answer if you feel inclined. After this
> mornings SPF discussion . . . well, I'll ask anyway.
>
> An organization I know of is moving to o365 from their own mail
> system. For a variety of reasons, the migration cannot be
> completely resolved "day one". Thus, we concocted a scheme of
> keeping MX as is, and having the current system simply relay messages
> to o365 and have users start using o365 right away.
>
> Everyone thought this a great idea, solving several issues, until,
> suddenly, last evening, I realized that we would be sending email
> that might appear "spoofed". That is, from IP's that are not
> published as "ours".
>
> I've not run this by any one else yet, hoping to either allay my
> concerns, or raise the alarm and have some suggested solutions, by
> asking a well versed group.
mainly FTR:
http://www.bittitan.com/products/migrationwiz/
we've used these often at $dayjob to move large client inhouse setups to
Appriver/O365. Does wonders.
Re: SOT - Fowarding mail to new service, keeping same MX, pitfalls
Posted by Dave Pooser <da...@pooserville.com>.
On 10/22/15, 11:45 AM, "Joe Acquisto-j4" <jo...@j4computers.com> wrote:
>Thanks for all replies. It seems resolvable for SPF anyway. I have
>this vague concern about PTR, but that may not count for much anyway
>these days.
Anyone who insists that an address $DOMAINPART must equal server PTR is
already blocking millions of legitimate messages from Google Apps users,
hosting providers, and of course O365. Honestly, do you really need to
communicate with anyone that clue-free?
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
Re: SOT - Fowarding mail to new service, keeping same MX,
pitfalls
Posted by Joe Acquisto-j4 <jo...@j4computers.com>.
>>>> Dave Pooser <da...@pooserville.com> 10/22/15 11:53 AM >>>
>(Oops, forgot to include the list first time. Need more caffeine....)
Me too.
>>An organization I know of is moving to o365 from their own mail system.
>>For a variety of reasons, the migration cannot be completely resolved
>>"day one". Thus, we concocted a scheme of keeping MX as is, and having
>>the current system simply relay messages to o365 and have users start
>>using o365 right away.
>>
>>Everyone thought this a great idea, solving several issues, until,
>>suddenly, last evening, I realized that we would be sending email that
>>might appear "spoofed". That is, from IP's that are not published as
>>"ours".
Err. (cough,cough) "theirs".
>This is why SPF has "include" syntax. Check with the Microsoft rep for the
>exact details, but it will probably mean something like adding
>"include:spf.messaging.microsoft.com include:spf.protection.outlook.com"
>to your current SPF record.
>--
>Dave Pooser
>Cat-Herder-in-Chief, Pooserville.com
Thanks for all replies. It seems resolvable for SPF anyway. I have this vague concern about PTR, but that may not count for much anyway these days.
Re: SOT - Fowarding mail to new service, keeping same MX, pitfalls
Posted by Dave Pooser <da...@pooserville.com>.
(Oops, forgot to include the list first time. Need more caffeine....)
>An organization I know of is moving to o365 from their own mail system.
>For a variety of reasons, the migration cannot be completely resolved
>"day one". Thus, we concocted a scheme of keeping MX as is, and having
>the current system simply relay messages to o365 and have users start
>using o365 right away.
>
>Everyone thought this a great idea, solving several issues, until,
>suddenly, last evening, I realized that we would be sending email that
>might appear "spoofed". That is, from IP's that are not published as
>"ours".
This is why SPF has "include" syntax. Check with the Microsoft rep for the
exact details, but it will probably mean something like adding
"include:spf.messaging.microsoft.com include:spf.protection.outlook.com"
to your current SPF record.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com