Flat Forward & DMARC

We are using a cloud helpdesk provider that requires us to use flatforward to relay emails from outside clients (people using yahoo, aol, comcast, gmail), to an internal GW resource (servicedesk@ourgwdomain.com) out to the saas email (big_ugly_uid_account_name_@SAASservicedesk.com ) to open a service ticket.

This SAAS company is using google to host their mail.

This used to work great for a few months until recently the SAAS host (gmail) started enforcing DMARC. Now, anyone emailing from big DMARC proponents (aol, yahoo, comcast, gmail) get NDR'd when the flatfoward relays to the SAAS company.

The SAAS company is no help. they are pointing fingers at GroupWise.
My understanding is, since GroupWise is flat-forwarding it appears to the Saas host that the original message is coming from a non yahoo/aol/comcast/gmail and gets dumped. I would expect this behavior, since we are non-authorized mail servers for those domains.

Any thoughts/suggestions?

Frank

Tags:

  • On 17.08.2015 21:26, vodobaas wrote:
    >
    > We are using a cloud helpdesk provider that requires us to use
    > flatforward to relay emails from outside clients (people using yahoo,
    > aol, comcast, gmail), to an internal GW resource
    > (servicedesk@ourgwdomain.com) out to the saas email
    > (big_ugly_uid_account_name_@SAASservicedesk.com ) to open a service
    > ticket.
    >
    > This SAAS company is using google to host their mail.
    >
    > This used to work great for a few months until recently the SAAS host
    > (gmail) started enforcing DMARC.


    How is/can this remotely by your problem? It's theirs (of the SAAS
    provider), and theirs only. Their requirement, their mail provider they
    pick and have no control over. That problem isn't even groupwise related...

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • In article <vodobaas.71s9pb@no-mx.forums.microfocus.com>, Vodobaas
    wrote:
    > The SAAS company is no help. they are pointing fingers at GroupWise.
    > My understanding is, since GroupWise is flat-forwarding it appears to
    > the Saas host that the original message is coming from a non
    > yahoo/aol/comcast/gmail and gets dumped. I would expect this behavior,
    > since we are non-authorized mail servers for those domains.


    Of course they aren't, Your SAAS is just working to make things more
    secure. The problem isn't the particular email system, but that you are
    using it to fake out where you are going to, and that is the thing that
    looks suspicious and therefor is now blocked just like open relays have
    been for a while.

    So why are these clients not sending the requests directly to the SAAS
    helpdesk? It isn't that they need to be tied to your domain, otherwise
    you wouldn't be using flatforward in the first place.



    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • In article <w9EAx.386$In6.252@novprvlin0914.provo.novell.com>, Massimo
    Rosen wrote:
    > How is/can this remotely by your problem?


    Only in the fact that he has something he is responsible for that
    doesn't work anymore. In this case it is using a feature that is going
    the way 'Open Relay' did over a decade ago, back in the early days of
    the spam wars, and for much the same reasons.
    Like when 'Open Relay' started being blocked, we now have the same
    transitions needed to get away from flat-forwarding and is now Frank's
    challenge.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Andy,

    Am 18.08.2015 um 20:22 schrieb Andy Konecny:
    >
    > Of course they aren't, Your SAAS is just working to make things more
    > secure.


    I read it that google, which the SAAS uses makes that.

    > The problem isn't the particular email system, but that you are
    > using it to fake out where you are going to, and that is the thing that
    > looks suspicious and therefor is now blocked just like open relays have
    > been for a while.
    >
    > So why are these clients not sending the requests directly to the SAAS
    > helpdesk? It isn't that they need to be tied to your domain, otherwise
    > you wouldn't be using flatforward in the first place.


    I read that the Saas company *requires* it that way. Hence my comment
    that this is exclusively their problem. They require it to be broken,
    and probably don't even know that (yet).

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • In article <ofOAx.656$Qq2.94@novprvlin0913.provo.novell.com>, Massimo
    Rosen wrote:
    > I read that the Saas company *requires* it that way. Hence my comment
    > that this is exclusively their problem. They require it to be broken,
    > and probably don't even know that (yet).


    I was trying to figure out how that was exactly relevant, so was
    phrasing it to help Frank manage the issue and deal with the SAAS on
    this issue. Just pointing fingers and washing ones hands of an issue
    generally doesn't help much, so have hopefully been usefully
    constructive in getting the problem fixed. The root cause being a
    process that relies on a trick that gets in the way of identity proof
    and as such is starting to be blocked.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!