AWS SES has an API for programmatically sending a bounce email in reply to a received email—SendBounce. However, emails sent through SendBounce—unlike "normal" emails sent through SendEmail—only contain a DKIM-Signature for amazonses.com. Since bounced emails use MAIL FROM: <>, both of these result in SPF and DKIM alignment failure, and thus DMARC failure.
With this, is it even possible to achieve DMARC compliance for emails sent with SendBounce? And is there a good reason why SES does not include a DKIM signature with the From: domain for SendBounce emails?
Example
SES email domain: email.com
MAIL FROM domain for email.com: from.email.com
DMARC record (_dmarc.email.com): v=DMARC1; p=quarantine
Note: Because adkim and aspf tags are omitted, the DMARC conducts alignment for DKIM and SPF in "relaxed" mode.
A sample email sent with SendEmail has the following:
From: header: normal#email.com
HELO identity: a27-123.smtp-out.us-west-2.amazonses.com
MAIL FROM: <01010181add736ef-0f477553-2014-4704-b7ee-a030525d7a66-000000#from.email.com>
from.email.com is a subdomain of email.com, which achieves relaxed SPF alignment.
DKIM-Signature: d=amazonses.com
DKIM-Signature: d=email.com
email.com is exactly email.com, which achieves strict DKIM alignment.
However, an email sent via SendBounce has:
From: header: mailer-daemon#email.com
HELO identity: a27-9.smtp-out.us-west-2.amazonses.com
MAIL FROM: <> (empty, as expected for a bounce message)
DKIM-Signature: d=amazonses.com
Note that for the bounce email, neither the HELO identity nor any of the DKIM signature domains match the From: domain of email.com. Hence, DMARC fails.
Possible workaround (hack)
Given these limitations of bounce messages sent with SendBounce, one workaround which preserves DMARC (with a p=reject or p=quarantine policy) for normal emails but disables it for bounce emails is to designate a subdomain of email.com with DMARC explicitly disabled.
For example, set _dmarc.bounce.email.com to v=DMARC1; p=none, and use mailer-daemon#bounce.email.com as the From: address of SendBounce. This allows SendBounce emails to not end up in spam or dropped outright (per DMARC) but hardly seems like an ideal solution.
Related
I am writing a addin that requires the email content in MIME format. Now I am using the ewsurl(), getCallBackTokenAsync(), and Office.context.mailbox.itemId api's to find out the EWS url, access token, message id and sending it to my back-end via Ajax. My back-end sends a SOAP request to EWS and downloads the email message. Is this approach correct?
My main concern is will there be any throttling if the EWS endpoint sees too many request coming from the same machine. For example, several users(say couple of hundreds) in an organisation could use the add-in concurrently. In this case , the add-in back-end could send several concurrent requests to EWS. Would EWS implement some throttling if it sees too many requests coming from the same add-in / the same back-end machine
Are there any alternative approaches?
This is the only approach at the moment. Neither Office.js nor Graph supports getting the raw email message. Given that add-ins run within the context of a single email, I can't imagine this would result in more than a couple of calls per second at most so I wouldn't be too concerned with throttling.
I am writing a addin that requires the email content in MIME format.
You will not be able to get original MIME message. Exchange doesn't store MIME content. You may get generated MIME content which done on the fly by Exchange and this conversion is expensive. Resieved MIME message has nothing to do with original MIME received by Exchange, so why bother? The maximum you will be able to get with EWS requests is original message headers (PR_TRANSPORT_MESSAGE_HEADERS), but not entire original MIME message.
Limits: If you would use EWS requests from the client (makeEwsRequestAsync ) you would be limited to 3 asynchronous calls and 1 Mb of response. If you do this from your server you will be able by pass those limits. More on this: Limits for activation and JavaScript API for Outlook add-ins
I'm using NServiceBus with MSMQ and I'm trying to send a message from a computer in one domain to another computer in a different domain. A trust exists between the two domains.
The two computers can ping each other, but only if they use the fully-qualified name of the computer, e.g. pc01.mydomain.net.
In the config file on the computer that sends the message, I've ensured my MessageEndpointMappings are correct by setting the Endpoint attribute to be "Endpoint#pc01.mydomain.net". If I try to send a message then it arrives OK at the pc01 endpoint.
However, when the pc01 endpoint tries to send the reply back to the sender (let's say that computer's name is sender01.anotherdomain.net) it fails to deliver the message. When I check Bus.CurrentMessageContext.ReplyToAddress it returns "queuename#sender01". I believe (although I can't prove it) that if the ReplyToAddress was "queuename#sender01.anotherdomain.net" then the reply would arrive in the correct queue as desired.
So I just need a way to ensure the ReplyToAddress has the fully-quailfied name of the computer (sender01.anotherdomain.net) rather than just the computer name (sender01).
Does anyone know how to do this?
Create an outgoing transport message mutator on the sender that updates the ReplyToAddress accordingly.
In v4 you can override the way we resolve machine names by changing the RuntimeEnvironment.MachineNameAction func.
This is not a programming question per se, but it is related to a c program that I am trying to make in order to respond the ip sla control messages sent by a cisco router. I know that it uses MD5 using and a key chain in order to authenticate the packet (Could be MD5 or HMAC). I know about the theory about HMAC and MD5 and all about the message and the key and all that stuff that the theory on the book give us... but I have a question that does not seems very simple at least to me that is at the end Which is the "message" that is hashed and added to the packet so the other end could know that he packet is valid?
Thanks for your help...
EDIT:
I have two routers one acting as a ip sla generator and another one as an ip sla responder. The ip sla generator authenticate the data sent by using MD5 and a key.
Capturing the packets that left the ip sla generator interface with Wireshark I found this:
Packet not Authenticated:
IP header
4500005000000000ff1136e3c0a801c3c0a801a6
UDP Header
e2e607af003ccdbd
Payload
01040034000000000004001000000000c0a801a6ea6014500001001c000000000000000000000000000000000000000000000000
Packet Authenticated with key "cisco":
IP Header
4500005000000000ff1136e3c0a801c3c0a801a6
UDP Header
c20107af003cd296
Payload
01040034000000000004001000000000c0a801a6ea6014500001001c00000000*01ff0000b9c0ae94fec238bd43d13129a6625eda*
*where at the end of the payload you could see 0x01ff that is the key number used to authenticate the packet and 0xb9c0ae94fec238bd43d13129a6625ed that is the authentication string
Capturing another Authenticated packet with key "cisco" I got this:
IP Header
4500005000000000ff1136e3c0a801c3c0a801a6
UDP Header
d47607af003cc021
Payload
01040034000000000004001000000000c0a801a6ea6014500001001c00000000*01ff0000b9c0ae94fec238bd43d13129a6625eda*
As you could see the UDP header changes but the authenticated message remains the same, that lead me to infer that the message to hash is just the payload but hashing the following combinations does not produce the authentication needed:
MD5 of the payload not authenticated
MD5 of the payload not authenticated + key in Hex
Hmac-Md5 of the payload not authenticated
Hmac-Md5 of the payload not authenticated + key in Hex
A lot more combinations too long to be listed...
So i think that the message is not as simple as the payload or the Authentication Method used by Cisco is not standard. Am I missing something? or There is something else I could try?
Thanks for your help...
The answer is: yes, it depends on the protocol (which I cannot find). I don't see any mention of HMAC in the documentation though, so it is much more likely that the key is included as last part in the hash calculation, but is not in the package (of course). This is different from appending zero's. The plain MD5 hash is then used as some poor man's authentication scheme.
All this from the confusing docs from Cisco and the relatively hard to read question - and general knowledge of crypto, of course.
my task is to retrieve a set of messages from GMail via POP3 (no IMAP).
I can do RETR MSG #, and it is prohibited to delete.
Fetchmail and procmail are constantly trying to download a same set of new, unread messages (this part goes to ServerFault). Is there a header specially designed to distinguish previously read messages? Or I should do checksum of message body/subject/date?
The POP3 protocol doesn't support a read/seen sort of flag. Some servers support a non-standard header like X-Seen which acts like a read flag, you'll have to use the TOP to get a message's headers and see if it's been set (well more to determine if it's even there).
It's supposed to be up to the client to cover read flags in POP3, but the good news is you don't need to do a checksum, just use the UIDL which will give you a list of non-changing, unique IDs for the messages in the inbox, or if called with a message # will give you the unique ID for the message in that position in the mailbox (since you can't guarantee message position in the mailbox if other client's are accessing and may be deleting).
Try to control messages with message-id
Message message ;
....
String messageId = message.getHeader("message-id")[0];
For what ever reason, a critical third peaty webservice functions like this. I can connect, send a request, and receive valid response, but i still get the error message. This only happens on one server.
"The incoming message was signed with a token which was different fron what used to encrypt the body. This was not expected." (sic)
This only happens on one server, but it's critical that I get the data. I don't have control over the server and while I'm aware what the message means, frankly I don't care. It's their call how they configure their own servers and send back the proper information. All I want is the data.
Is there any "shut up and deal with it" security setting in WCF so I can get data properly from the server?
What kind of tokens are you using? Certificates? If so, this article might be useful: "How to: use different X509 Certificates for signing and encryption". In particular, look at the part that reads "To use multiple certificates on the client".
I had to open up a trouble ticket with Microsoft to solve this. Those guys are good and it raised up pretty high up the chain.
In the end it was something simple - the certificate on my machine was somehow corrupt. I had delete it and reinstall it then everything magically began to work.