Address sent count increments but email does not arrive.

[rux]

Hello fellow SGers. Can you please help find the problem? I've got 2
reproducible cases where email sent to SG address creates the address
at SG (if new) and increments the sent count but does not show up at the
protected address. Starting to get concerned because I don't really
know everything that is missing. The problem seems to have begun
(or become worse) about a month ago.

The problem seems similar to this thread, but in my case Reply Address
Masking is disabled and it is consistently reproducible.

"New disposible address shows sent count but no emails arrive"
viewtopic.php?p=7262

I have no watchwords, and the only option enabled is "eaten message log".
All other options are disabled. The missing emails are not listed in the
eaten log. Many other emails are coming through the disposable addresses
just fine.

This might be important: The trusted address is hosted by Yahoo. I have
checked filters, spam folder, etc. and cannot find any indication of the
missing emails.


Case 1:
-------
The missing messages are from newegg.com . For several years, some of their
message (such as eblast advertisements) did not come through, but order related
emails did arrive. Beginning about a month ago, nothing comes through from that
sender. Using a new SG address causes the address to be created at SG and shows
a sent count of 1 but the email does not arrive at the protected address. The
last email received through SG from Newegg was October 5, 2014 and the first
certain missing message was Oct. 24, 2014.

This can be tested, if you have an account, by changing the email address.
(Note that email address is also the account ID, so keep track of what you
changed it to for future logins.)


Case 2:
-------
Happens with multiple (all?) users sending from yahoo.com . The message does
not bounce back. Messages from yahoo.com were coming in regularly through
October 1, 2014. None have arrived since then. (There is a notable exception.
Some Yahoo accounts allow changing the "from" address. Email sent using Yahoo
but having a non-yahoo "from" address does arrive properly.)


Can anyone help debug?
Especially, can anyone with a protected address hosted by Yahoo
confirm this?

Thank you!

[josh]

I will look into it -- when we've had similar reports before, we've been unable to figure out what was going on (not specifically about newegg, just similar situations)

[rux]

I'm no expert, but here is what I think is happening.

After finding a third sender having this problem, searching for "yahoo reject email"
suggested that DMARC policy changes at senders are causing trouble with mailing
lists and forwarding. All 3 of the sender domains that I was able to identify as
having the problem (address count increments but email not delivered) have DMARC
"p" tag set to "reject".

For more details, search for "forward" multiple places in the DMARC FAQ
http://www.dmarc.org/faq.html . Especially look at the first entry under "Receivers".

What appears to be happening is that SPF generally fails with forwarded email, and
DKIM also fails due to SG modifying something about the message. Enabling the SG
option "hide subject tagline" allows DKIM to pass and the message gets through.
Have confirmed this setting fixes the problem with both cases identified in the
original entry above.

So it really looks likely to be the same underlying issue as with reply
address masking. With the recent DMARC usage, SG "reply address masking" must
be disabled and SG "hide subject tagline" must be enabled. Those options have
basically been rendered useless because they can cause otherwise vaild email to
be rejected.

[josh]

nice work!

not sure what to do about it, though.

From the FAQ:

>Headers protected by DKIM should not be modified in any way ...

I suppose the From: and the Subject: headers are protected by DKIM

The tagline feature modifies the Subject: header - you can turn that off, and then the same information goes into a new custom spamgourmet header, which is OK with DKIM, but invisible to you unless you view the headers of the message or modify your mail client to display that information to you somehow.

The From: header modification is *the way* that reply address masking works -- if DKIM forbids modification of that header, then it really can't work unless we put the redirection email in a custom header and then either:

1) you view the headers of the message and copy paste the redirection address into the To: blank for your reply - not transparent at all, and a total PITA or,

2) *you use a modified email program that sends your reply to the redirection address contained in the spamgourmet custom header instead of the one in the From: header* - more silliness

spamgourmet sure gets a lot of friendly fire from other spam fighting technologies...