I'm using Postfix + OpenDKIM to send emails. Should I sign X headers (X-Confirm-Reading-To, X-Unsubscribe, X-Priority, etc) in DKIM?
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=mydomain.com; s=mail; t=1435840997;
i=no-reply#mydomain.com;
bh=5n7rgNH/UhgzXvjmn6zu+M1BL29tq5L9PEZ7SB3uQgI=;
h=To:Subject:Message-Id:From:X-Confirm-Reading-To:
Disposition-Notification-To:Return-Receipt-To:List-Unsubscribe:
List-Id:Date:X-Unsubscribe:X-Priority;
b=vxfGzczj3S4wm1QtlrPPisyi2FsbDPP+gSSEyx/VWd09xdqSiLwdsn5vJS3SF5KoB
etbHaJvmfvpbklJLwDPM4g7rRKaRmYXE3X02+E/DzsHFEz3TNPhPfkhNslMefRLf3h
uq+juAwccQkzjxvvF5W4pukSJr1+Rw7NviukpZT5RSusiKSmJjFLjQavKCFSFme/bR
u2zTCMEN1JUE5cLXKJV6aFfTl16HRXYimTNvI2pLGJijxku8zKaxrgQevQJM4v3EDX
vs+gtOhw9t3kJI6OJsmJJyifiBRadl0/D3WUpvqYKGGFyzFPb28zvsI+h/AAOmapbM
4WeE3vdYLb2Hg==
Which headers should be signed in DKIM?
You can sign custom X- headers, but it's not required.
From http://dkim.org/specs/rfc4871-dkimbase.html#choosing-header-fields:
The following header fields SHOULD be included in the signature, if they are present in the message being signed:
From (REQUIRED in all signatures)
Subject
Date, Message-ID
To, Cc
MIME-Version
Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description
Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Message-ID
In-Reply-To, References
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
The following header fields SHOULD NOT be included in the signature:
Return-Path
Received
Comments, Keywords
Bcc, Resent-Bcc
DKIM-Signature
Optional header fields (those not mentioned above) normally SHOULD NOT be included in the signature, because of the potential for additional header fields of the same name to be legitimately added or reordered prior to verification. There are likely to be legitimate exceptions to this rule, because of the wide variety of application-specific header fields that may be applied to a message, some of which are unlikely to be duplicated, modified, or reordered.
There's no compelling reason not to: it wastes a few bytes, that's all. If you get more benefit than the cost then sign them.
Related
Please, let me know whether my understanding of these things is correct:
Email-message consits of two parts: email-message envelope and contents of an email-message.
Email-message envelope is an information that is formed step by step during
SMTP-handhaking phases on a path of a message from sender's mailbox
to reciever's mailbox (during exchanging command-reply pairs between each
SMTP-client and SMTP-server on a path).
Header section is one of the two parts of a content of an email-message
(along with message body), and initially consists of the lines written by sender along with the body of the message in his email client.
Body of the email message - this thing is self-explanatory.
RFC 5322 specifies the format of the email-message content (header section and message body), and RFC 5321 specifies the work of the SMTP protocol.
Although header section of the email-message is initially formed by sender of email-message along with the body of the message (in his email-client), this header section may be further extended with some header fields containing envelope information during the path of the email-message through different SMTP-servers. For example, SMTP-server can append a new "Received:" header line to the header section. These modifications of header section must be performed according to the rules from RFC 5321 and after each of these modifications the resulting header section must me consistent with the format specified in RFC 5322.
When we open a received email-message with an email-client GUI, we see only the message body and a part of the header section of the message that was initially written by sender of email-message in his email client. But if we want to look at the full header section of the message (with those header lines containing envelope information, that were appended by SMTP servers) we can use options like "show original" in Gmail.
Since nobody answered, I will do it - I have spent some days looking for information about it, have read in RFC 5321 and RFC 5322 the most important moments and hasn't found any contradictions to the assumptions in the question.
Somebody in my company is being subject to phishing. My first suggestion was just to change the password. However after awhile I received a fake mail from her address again.
Looking at the raw source of the email I found that there is another person's email in X-Sender-ID and I'm wondering who that might be. Is that the person who sent the email or can it be an account that has been hijacked? (I replaced the email with "somebody#host.com")
X-Virus-Scanned: OK
Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: somebody-AT-host.com) with ESMTPA id DF2788019C;
Fri, 21 Nov 2014 07:54:42 -0500 (EST)
X-Sender-Id: somebody#host.com
Received: from smtp.emailsrvr.com ([UNAVAILABLE]. [2.133.148.211])
by 0.0.0.0:587 (trex/5.3.2);
Fri, 21 Nov 2014 12:54:46 GMT
What is X-Sender-ID? And what is the email it contains?
My deliberations are based on this RFC which describes the Privacy Enhancement for Emails which you are obviously using.
Basically it says about the X-Sender-ID:
[...] encapsulated header field, required for all
privacy-enhanced messages, identifies a message's sender and provides
the sender's IK identification component.
What does this mean?
First of all you have to check if the mail is properly signed. If thats the case you can be sure that somebody#host.com has a certificate. And you can be sure that the mail you received has been sent from this mail address.
I can't tell you the consequences which result out of this fact as I don't know how your company is deploying the certificates etc. ... the mail address/certificate could also have been hacked and thereby abused.
I hope this helps you for your further research.
While #LMF's answer is useful technical information, I'd like to offer a possible alternative explanation.
Spammers who are not familiar with e-mail (and PHP programmers with no other malicious intent) tend to succumb to cargo cult programming when it comes to email headers. In other words, if there is something they don't understand, they might think it does something useful, and include it in their message template.
Without knowledge about your email infrastructure, or other messages of yours to compare to, I would simply assume everything below the top-most Received: header is forged, and basically without meaning.
If you have a system which runs something called trex (maybe this one?) and it really manages to write a Received: header like that, I might be wrong. The format needlessly deviates from the de-facto standard Sendmail template in a few places, but it's not technically wrong (the format is basically free-form, but introducing ad-hoc syntax makes it harder to guess what the fields mean).
Again, more information about what your typical email (and your correspondent's typical mail) looks like, this is heavy on speculation.
The x-sender-id, along with the x-recipient-id are used to specify which interchange key was used in the broadcast of the message.
X-Sender-ID entity_id : issuing_authority : version
X-Recipient-ID entity_id : issuing_authority : version
The first field contains the identity of the sender or receiver. The first field is mandatory, must be unique, and must be formatted as user#host whereas the host is a fully qualified host address.
The second identifies the name of the authority which issued the interchange key.
The third field specifies the specific type of interchange key which was used. This is represented by an alphanumeric string defined by the issuing authority to label and organize the numerous interchange keys issued by that authority. It is recommmended that they use a timestamp but is not always the case.
If the field values of the x-sender-id second and third field are identical to that of the x-recipient-id they may be only listed in the field which is defined last.
Further Reading
"Distributed Computing & Cryptography: Proceedings of a DIMACS Workshop"
Hi I am new to the mail domain and trying to figure out to parse the digital signature out of the DKIM-Signature header. The "b=" tag gives the value for the digital signature. Is there any ordering in where the "b=" tag should appear (is it always the last tag in the header)?
No there is no ordering in where "b" tag should appear in the DKIM-Signature header. You may very well know that DKIM is self-signatory i.e the signature is computed including the "DKIM signature" header. This has influence on why "b" tag is added at the end of the signature. It is just done for the sake of convenience of adding the tag's value at the end at once after the computation digital signature of DKIM's signature header.
When someone loses track of an email that has been sent to them, and brings that to the sender's attention, it is common practice for the sender to simply forward or re-send the original email. I want to know if there is any [semi-]standard way to reference a specific email, such that a mail client could open that email if it has a copy of it. This might be in the form of a URI, or possibly some other form. Such a URI might reference the sender, recipient, date, time, or other headers that [should] remain intact between sender and recipient.
The Message-ID is a globally unique identifier for messages.
Note that the Message-ID header is optional, but recommended:
Though listed as optional in the table in section 3.6, every message SHOULD have a "Message-ID:" field.
RFC 2392 specifies the URI scheme mid (which was already reserved in RFC 1738):
The "mid" scheme uses (a part of) the message-id of an email message to refer to a specific message.
An example from RFC 2392:
previous message, shows how the approach you propose can be used to accomplish ...
My software is working with incoming e-mail from the one and only particular sender (let it be SantaClaus#hetnet.nl). According to RFC-2616 section 14 "From" header
MAY be used for logging purposes and
as a means for identifying the source of invalid or unwanted
requests.
That's exactly what I needed, so I wrote a code, which ignores all the messages where "From" field doesn't equal SantaClaus#hetnet.nl. It worked good, but one day things changed, and now all the messages form Santa Claus contains a different string in "From" field (exactly <SantaClaus#hetnet.nl>).
I already fixed my code, but I just wonder, is this header legal? Because the same RFC-2616 section 14 says:
The address SHOULD be machine-usable,
as defined by "mailbox" in RFC 822 [9]
as updated by RFC 1123 [8]:
From = "From" ":" mailbox
An example is:
From: webmaster#w3.org
Note the absense of angle brackets. But at the same time, many e-mail messages I receive on my Gmail account has something like this in the "From" field: "Santa Claus" <santaclaus#hetnet.nl>
RFC-822 allows email addresses to be specified either by a pure email-style address, called an "addr-spec" (e.g., name#host.domain); or by using a nickname ("phrase") with the email-style address (the "addr-spec") enclosed in angle brackets (Foo Bar <foobar#host.domain>). Your sender has gone from the first format to the second format, although here the nickname part seems to be empty.
By the way, RFC-2616 is for HTTP; you're looking at the definition of an optional, and (I imagine) rarely-used, From: header in the HTTP protocol. That doesn't seem to have any direct relevance on email formats.