Issue DMARC issue with forward mail

[Sergio Manzi]

sorry, meant to say "re-srs", not "re-spf"!

 

[Sergio Manzi]

... and, by Jove, we have the factual evidence that when I forward directly to GMail, it gets through!

 

[G J Piper]

They says: "we simply pass the mail object on exactly as it is handled to us."
That's bollocks, I think: they are not "transparent" they receive and they send and there is trace of that in the headers
They should re-spf re-SRS the message, I think... I'll check the relevant RFCs, but not now... I haven't the time right now, sorry...

I agree... they can't possibly be not capable of examining the entire message if they are handling all kinds of rewriting on their end to add their own relay domain, etc to the headers. They have their own mail queue — how can that not be accessible!? They even artificially defer/hold outgoing emails that have been blocked once so recipient servers are less likely to blacklist me — they have a whole "Suppressions" section in settings for me to control this behavior! MY server queue isn't being used at all because the postix settings are set to send them everything to be processed for SMTP! WTF.

I think I'm going to attach a link to this thread to my Sendgrid support ticket.

 

[Sergio Manzi]

It is all in this paper by "Shevek": in a multi-hop scenario (our case) every intermediate MUST alter the envelope sender (Return-Path) with his own SRS (see from point 2.4 onward in the paper). It will be an "SRS1" address.

You (and "they"!) might also want to give a look at the Wikipedia articles about Sender Rewriting Scheme and about Email Forwarding

If they "simply pass the mail object on exactly as it is handled to us", they are failing, and Plesk has nothing to do with their failure. They should understand what their business is and what technical intricacies it imply: they are paid for that, I guess. If they don't know already, they should interact with Yahoo and Google to understand what is expected from them! (but keep us informed here: the story is fascinating!)

========

But at the end of the day, I honestly think that the "original sin" lies in your choice of hosting in a "cloud" that doesn't allow you to directly send mail: really, try something else, with a couple of test domains and a temporary Plesk license...

As I already said I'm very happy with Digital Ocean and I love the integration I have between Plesk and their DNS.

BTW, if you ever decide do go with them you might consider to use this link: DigitalOcean: Cloud Computing, Simplicity at Scale so that I receive a little bit of discount from them!

 

[G J Piper]

BTW, if you ever decide do go with them you might consider to use this link: DigitalOcean: Cloud Computing, Simplicity at Scale so that I receive a little bit of discount from them!

If I switch, I'll use your link, yes.

 

[Sergio Manzi]

If I switch, I'll use your link, yes.

Thanks!

 

[MarkM]

I’ll second DO, I have several customers between them and Vultr.

 

[G J Piper]

Here is the latest response from Sendgrid. ALL domains I run have correct DMARC DNS entries that state "p=none" and not "p=reject" so that Gmail and any others should just allow the email through regardless of the DMARC outcome if MY domain is actually what they are checking! Ugh.

Edited Note: I see they are actually showing that my server is rewriting the "Env-From" and not the "From" address... Can anyone verify that Plesk is handling it correctly? Or, is there any way for me to verify their claims independently?

The domain I host that forwards in their example here is thecabinetshope.com —

 

[Sergio Manzi]

@G J Piper I'm sending you a PM with my email address so that you can forward me the Sendgrid answer in order to more easily access the documents they're citing: doing that from the jpeg image is a huge pain in the back...

Anyway, from a first look, I'm seeing some fallacies in their answer:

They say that there are "zero SPF failures logged" and that "block reason is for DMARC failure": don't they understand that DMARC is just a policy to be applied in case of either DKIM or SPF failures and not a separate authentication/verification mechanism? And don't they understand that SRS is a mechanism to have SPF working in case of forwarded messages?

 

[Sergio Manzi]

... just an idea, to (possibly...) nail them to the wall: for one of the domain you're hosting (maybe a sub-domain so that you do not create problems to an active domain...) set up a DMARC policy with p=reject and then try directly (e.g via Roundcube) sending mail from that (sub-)domain to GMail via Sendgrid and see what happens: I'm expecting it to fail.

P.S.: of course for this experiment to be valid their (Sendgrid) IP addresses should not be cited in your (sub-)domain SPF policy: this is to simulate the conditions of when you can't manage the SPF policy of a domain, like when you are forwarding mail originating from a domain you do not manage (e.g. Yahoo)

 

[Sergio Manzi]

... I'm starting to think that all this SPF/SRS s*it is essentially flawed, as it is demonstrated by your case (issues with remailers/forwarders): a valid DKIM signature of the original message should be all that is needed... or am I missing something?

 

[Sergio Manzi]

In case there are others following the thread and the @G J Piper issue: I had an email exchange with him and had access to his interaction with Sendgrid.

What emerges is that Sendgrid (for reasons I can also agree with...) is not willing to alter in any way the content that is "handed to them".
This of course precludes a solution for forwarding email originating in some domains with strict DMARC policies and dispatched to other domains strictly adhering to those policies.

Forwarding can always be problematic in today Internet where most mail is originated by spammers/phishers who always try to "pretend to be others" often using (pseudo-)forwarding mechanisms to hide themselves.

This has brought to the birth of authentication mechanisms (such as SPF / DMARC) which do not nicely coexist with forwarding.

SRS is a mechanism (which BTW is not sanctioned by any RFCs...) which tries to overcome this difficult coexistence, but IMHO is implemented in such a way that creates other issues like e.g. limitations in the email address length (beyond those established in RFCs), and, as in this case, difficulties in using relay agents.

From a practical point of view, in this particular case (forwarding to a single GMail mailbox) the compromise solution is... to not forward at all and have instead the GMail account to "pick-up" mail from the local Plesk hosted mailbox via POP3 or IMAP.

Hope this can help others too...

 

[G J Piper]

Just an update... Google has finally agreed to open up their SMTP ports in the near future!
I'll soon be quitting $80/mo SendGrid for good! Wooohoooo!