mirror of
https://github.com/Pro/dkim-exchange.git
synced 2026-04-25 17:05:55 +03:00
[GH-ISSUE #99] Signer doesn't sign NDR with emtpy FromAddress #76
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mr-flibble on GitHub (Oct 8, 2015).
Original GitHub issue: https://github.com/Pro/dkim-exchange/issues/99
Hello, my DKIM signing is working fine, but i noticed strange Warning in Application event log from source Exchange DKIM:
Invalid from address: '<>'. Not signing email.
I have about one hundred of these events every day. (With log level Warning)
With debug event level enablet I get these events :
CSV here http://pastebin.com/Xv6MPPSw
I have :
Exchange 2013 CU7 (15.0.1044.25)
2012 R2
DKIM signer 2.1.4
Please do not know where is the problem? Thank you.
@Pro commented on GitHub (Oct 8, 2015):
It seems that your server is sending E-Mails where no From address is set, therefore you get this error (see
github.com/Pro/dkim-exchange@9deeca73ab/Src/Exchange.DkimSigner/DkimSigningRoutingAgent.cs (L142))Can you use the MS Exchange Toolbox to see if the E-Mails corresponding to the given Event Log time are valid?
@mr-flibble commented on GitHub (Oct 8, 2015):
you're right! There are some undeliverable mesages
Unfortunately I can not find how to avoid them anywhere. Maybe it could be related to the quarantine mailbox where messages come even to nonexistent recipients.
On the other hand "BlankSenderBlockingEnabled" , is enabled
do you have a clue? Thank you.
@Pro commented on GitHub (Oct 8, 2015):
To me it looks like your server isn't configured properly which has nothing to do with DKIM signer.
Unfortunately I can't help you with that.
The indicated source IP "255.255.255.255" is also a bit strange.
Maybe googling helps you further.
@Zuz666 commented on GitHub (Oct 8, 2015):
Hi.
I have same issue with automatic responses. Message Tracker show only a "Return-Path" as "<>"., but "Sender" and "Recipients" is a valid e-mail addresses.
With Exchange Server 2010 (and 2007’s latest Service Pack) Microsoft has changed the behavior of automatic server based notifications, especially “Out of Office” replies to rely on RFC 2298. As per RFC 2298 Message Disposition Notification (MDN) messages should be sent with a blank sender. The OOF reply messages are Message Disposition Notifications. This means that the HUB Server replaces the senders name with a blank one while transferring it to the internet.
And now we get warnings like this: "Invalid from address: '<>'. Not signing email" from that code.
Whether there is a workaround?
Thank you.
@Pro commented on GitHub (Oct 8, 2015):
Thanks for the info.
I could add a check to see if the from address is empty. if it is, then the message will be simply ignored and no warning message will be shown...
@AlexLaroche commented on GitHub (Oct 27, 2015):
Could we just comment that part? (DkimSigningRoutingAgent.cs line 141-147)
Are remove the expression "mailItem.FromAddress.DomainPart == null" from the check?
@Pro commented on GitHub (Oct 28, 2015):
@AlexLaroche I think the best solution for this is to comment out the
Logger.LogWarningand keep the rest of the check, so that DKIM Signer silently ignores emtpy from addresses?@InfoStroy commented on GitHub (Oct 30, 2015):
@Pro The real problem is we have to sign all outgoing messages to implement DMARC policy like reject or quarantine. All DSNs and MDNs (aka Return receipts) have to be signed.
For MDNs (RFC 3798) - page 8
For DSNs (RFC 3461) - page 19
@Pro commented on GitHub (Oct 30, 2015):
@InfoStroy thanks for the info!
So this means that we also need to sign outgoing mails which have an empty from address.
This leads to the problem on how to detect the from domain part correctly to select the correct signing key. Currently this is done using the DomainPart of the FromAddress.
I need to check if it is stored somewhere in one of the headers
@Zuz666 commented on GitHub (Oct 30, 2015):
@InfoStroy thank you for your interest in the issue! You're right.
@Pro perhaps in this case it is necessary to use mailItem.Message.EmailMessage.Sender property (only when mailItem.FromAddress.DomainPart == null)