[lane]

Originally Posted by petergh

I have notced that Gmail sometimes(?) discards email forwarded mail if the sender domain has an SPF record that contains "-all". The real problem is that Gmail accepts the message but never delivers it, not even to the spam folder. This happens even if the forwarding service, in this case Fastmail, uses SRS rewriting.

It does sound, from your subsequent comments, that this is not a DMARC issue. I was not aware that Gmail would quietly drop any messages without a bounce to the sender; in fact, this is why I gave up Hotmail a number of years ago.

Is it possible somehow that Gmail is in fact giving a bounce response, but it is not making it back to yourself at the original test account? I do have one address (my wife's) at my domain forwarded with SRS from Fastmail to Google Apps (essentially Gmail), so I tried a test. I sent a test message with an executable attachment (which will be refused by Gmail) from an Outlook.com account to that address at my domain (hosted at Fastmail), which directs one copy to a Fastmail subfolder for insurance purposes and sends a second with SRS to Google Apps. The copy to Google Apps was indeed refused with a bounce message back to Fastmail (it was sent to the address SRS had rewritten as "SRS0=mr/t=WD=outlook.com=xxxxxx@srs.messagingengine.com") and Fastmail properly sent it back to the originating Outlook.com account. So the bounce message appeared in the original sending account, and everything worked properly as far as I can see.

So there are many links in the chain for a forwarded message:

1. The original message is sent to Fastmail. Fastmail will drop it quietly under certain circumstances, e.g., sent from a dial-up server, perhaps after greylisting.
2. Then Fastmail should perform SRS and forward it to Gmail. Perhaps Gmail may drop it quietly at this point, and that is very disturbing.
3. If the message is unacceptable to Gmail, say because it has an unacceptable attachment (exe or html file etc.) as in my test case, or because of an issue with SPF "-all", Gmail should generate a bounce at the smtp stage.
4. Gmail's refusal should be read by the sending Fastmail server at the smtp negotiation stage with the Gmail server, and Fastmail's server should generate a bounce reply to the recipient defined by SRS.
5. Fastmail should unwind the SRS recipient and send the bounce back to the original sender.
6. The original sending mail system might deliver the bounce or drop it.

I am not sophisticated enough to think of tests that you could perform that might unwind each of these possible points of failure. But it is certainly possible that Gmail is not dropping it quietly at step #2 and instead one of the other links is failing. Nevertheless, I understand your concern, and of course, unless you pay for a business Google Apps account, there is no one at home at Gmail to talk to about it.