Wandering Thoughts

Rejecting email at SMTP time based on the From: header address

Once upon a time (a long time ago), filtering and rejecting email based on the SMTP envelope sender (the SMTP MAIL FROM) was a generally sufficient mechanism to deal with many repeat spam sources. It didn't deal with all of them but many used their own domain in the envelope sender, even if they send from a variety of different IP addresses. Unfortunately, the rise of (certain) mail service providers has increasingly limited the usefulness of envelope sender address filtering, because an increasing number of the big providers use their own domains for the envelope sender addresses of all outgoing email. Unless you feel like blocking the provider entirely (often this isn't feasible, even on an individual basis), rejecting based on the envelope sender doesn't do you any good here.

This has made it increasingly useful to be able to do SMTP time rejection (and general filtering) based on the 'From:' header address. Many mail sending services will put the real spam source's email address in the From: and at least the top level domain of this will be consistent for a particular source, which means that you can use it to reject some of their customers but accept others. These days, MTAs (mail transfer agents) generally give you an opportunity to reject messages at the SMTP DATA phase, after you've received the headers and message body, so you can use this to check the From: header address.

(If you're applying per-destination filtering, you have the SMTP DATA error problem and may only be able to do this filtering if the incoming email has only a single recipient. Conveniently, the mail service providers that commonly obfuscate the envelope sender address usually send messages with only a single recipient for various reasons, including VERP or at least something that looks like it.)

I feel that From: address filtering works best on pseudo-legitimate sources of repeat spam, such as companies that are sending you marketing email without consent. These are the senders that are least likely to vary their top level domain, because they have a business and want to look legitimate, be found at a consistent address, and build up reputation. These are also the sources of unwanted email that are the least likely to be dropped as customers by mail service providers (for a collection of likely reasons that are beyond the scope of this entry).

There are plenty of potential limitations on From: header address filtering. Bad actors can put various sorts of badly formed garbage in the From:, you definitely have to parse it (ideally your MTA will provide this as a built-in), and I believe that it still technically might have multiple addresses. But as a heuristic for rejecting unwanted mail, all of this is not a serious problem. Most From: addresses are well formed and good, especially now that DMARC and DKIM are increasingly required if you want the large providers to accept your email.

(DKIM signing in 'alignment' with the From: header is increasingly mandatory in practice, which requires that the From: header has to be well formed. I don't know how Google and company react to badly formed or peculiar From: headers, but I doubt it helps your email appear in people's inboxes.)

PS: While you can filter or discard email based on the From: header in a variety of places, I like rejecting at SMTP time and it's possible that SMTP rejections at DATA time will trigger anti-spam precautions in the mail service providers (it's a possible signal of badness in the message).

(Some) spammers will keep trying old, no longer in DNS IPv6 addresses

As I mentioned the other day, in late September my home ISP changed my IPv6 allocation from a /64 to a different /56, but kept the old /64 still routing to me. I promptly changed all DNS entries that referred to the old IPv6 address to the new IPv6 address. One of the things that my home machine runs is my 'sinkhole' SMTP server, which has a DNS MX entry pointing to it. This server tracks which local IP address was connected to, and it does periodically receive spam and see probes.

Since this server was most recently restarted on November 10th, it's seen about the same volume of connections to each IPv6 address, the old one (which hasn't been present in DNS for more than a month) and the new one (present in DNS). Some of this activity appears to be from Internet scanning efforts, which I will charitably assume are intending to do good and which have arguable reasons to keep scanning any IPv6 address that they've seen respond. Other connections seem less likely to be innocent.

I'm pretty certain I've seen this behavior for IPv4 addresses long ago (I might even have written it up here, although I can't find an entry right now), so in a sense it doesn't surprise me. Some spammers and other systems apparently do DNS lookups only infrequently and save the IP addresses (both IPv4 and apparently IPv6) that they see, then use them for a long time. Still, it's a more modern world, so I'd sort of hoped that any spammer with software that could deal with IPv6 would handle DNS lookups better.

On the one hand, it's not like holding on to the IP addresses of old mail servers is likely to do spammers much good. If the IP address of a mail server changes, it's very likely that the old IP address will stop working before too long. On the other hand, presumably this mostly doesn't hurt because most mail servers don't change IP addresses very often. Usually the IP address you looked up two months ago (or more) is still good.

DKIM signatures from mailing list providers don't mean too much

Suppose, hypothetically, that you're a clever email spammer and you'd like to increase the legitimacy of your (spam) email by giving it a good DKIM signature, such as a DKIM signature from a reasonably reputable provider of mailing list services. The straightforward way to do this is to sign up to the provider, upload your spam list, and send your email to it; the provider will DKIM sign your message on the way through. However, if you do this you'll generally get your service cancelled and have to go through a bunch of hassles to get your next signup set up. Unfortunately for everyone else, it's possible for spammers to do better.

The spammer starts by signing up to the provider and setting up a mailing list. However, they don't upload a bunch of addresses to it. Instead, they set the list to be as firmly anti-spam, 'confirmed opt in through the provider' as the provider supports. Then they use a bunch of email addresses under their own control to sign up to the mailing list, opt in to everything, and so on. They may then even spend a bit of time sending marketing emails to their captive mailing list of their own addresses, which will of course not complain in the least.

Then the spammer sends their real spam mailing to the mailing list, goes to one of their captive addresses, copies the entire raw message, headers and all, and strips out the 'Received:' headers that come from it leaving the mailing list provider. Then they go to their (rented) spam sending infrastructure and queue up a bunch of spam sending of this message to the real targets, setting it to have a '<>' null SMTP MAIL FROM. This message has a valid DKIM signature put on by the mailing list provider and its SMTP envelope sender is not (quite) in conflict with it. The only thing that will give the game away is inspecting the Received: headers, which will say it came from some random IP with no listed headers that say how it got from the mailing list provider to the random IP.

The spammer set up their mailing list to be so strictly anti-spam in order to deflect complaints submitted to the mailing list provider, especially more or less automatic ones created by people clicking on 'report this as spam' in their mail environment (which will often use headers put in by the mailing list provider). The mailing list provider will get the complaint(s) and hopefully not do much to the spammer overall, because all of the list members have fully confirmed subscriptions, a history of successful deliveries of past messages that look much like the latest one, and so on.

I don't know if any spammers are actively doing this, but I have recently seen at least one spammer that's doing something like it. Our mail system has logged a number of incoming (spam) messages with a null SMTP envelope sender that come from random IPs but that have valid DKIM signatures for various places. In some cases we have captured headers that suggest a pattern like this.

(You can also play this trick with major providers of free mail services; sign up, send email from them to some dummy mail address, and take advantage of the DKIM signature that they'll put on their outgoing messages. The abuse handling groups at those places will most likely take a look at the 'full' message headers and say 'it's obviously not from us', and they may not have the tools to even try to verify the DKIM signature to see that actually, it is from them.)

The speed of updates for signatures of bad things matters (a lot)

These days (and for a long time), most spam, phish, malware, and so on (in email and other things) is recognized not through general rules, patterns, and processes (eg), but by seeing if the content matches any known signatures. Sometimes this is literally matching cryptographic hashes, but more often there's some sort of signature matching engine involved with various matching operators, conditions for combining them, and so on. ClamAV is one example that's mostly a matching engine, which means that in practice you need a collection of signatures to make it useful. Since signatures aren't general things, they have to be created by someone and then you have to get that newly created (or perhaps updated) signature.

What people have collectively found is that in practice, the speed of updating signatures matters, often a lot; in fact it matters enough that people are willing to pay for faster updates to collections of signatures. Why it matters is pretty straightforward; you're in a race against attackers. Attackers are perfectly well aware that the effectiveness of what they're doing goes down fast once signatures are available for it (or in general once people have had time to recognize what's going on, get their web landing page killed off, or whatever), so they generally try to get things done as fast as possible.

(I'm sure there are some slow-moving spam, phish, and malware campaigns that keep on going and going, but I don't think they're very common.)

However, attackers have their own speed limits; they can only send so much so fast, to you and to everyone else. Against many attackers, this gives you the chance to cut off at least some of their activities if 'you' can react fast enough, which broadly means if you can get signature updates fast enough. In more sophisticated environments, fast signature updates may also give you the chance to re-scan people's recently received email messages before people open them (or when they open them).

(Similar things apply to scanning files or recognizing signs of active malware, especially since these may already be delayed from the initial attack depending on how the attacker got to people. If you're getting people to download malware from a web page by sending them a bait message, you have to wait for people to read their email.)

So in general, the faster you get signature updates, the less you'll be exposed to (and for a shorter amount of time). The slower the updates, the more you're exposed to and the longer you're exposed. In the extreme case, sufficiently delayed updates are mostly useless, because the attacker campaign they're reacting to is over by the time you get the updates active.

(Of course you can try to delay receiving things (and thus checking them), but this tends to be unpopular with people. Like it or not, modern email is expected to get through rapidly and as a result is used for time sensitive things.)

We've seen this ourselves when we changed from a commercial anti-spam system for our email to one mostly based on free software and free signature data sources for the anti-malware, anti-virus (and anti-phish) part. Even with paying for some signature sources, the free system clearly was less effective at matching and blocking new malware, and we're fairly certain that part of this was that the commercial system's signatures updated quite frequently (and the company involved had a bunch of people working on keeping them up to date).

(I think this is something that's well known to people in the communities that use signatures, like anti-spam and (anti-)malware, but is perhaps not so obvious to people outside those communities.)

Some (big) mail senders do use TLS SNI for SMTP even without DANE

TLS SNI (Server Name Indication) is a modern TLS feature where clients that are establishing a TLS session with a server tell it what name they are connecting to, so the server can give them the right TLS server certificate. TLS SNI is essential for the modern web's widespread HTTPS hosting, and so every usable HTTPS-capable web client uses SNI. However, other protocols also use TLS, and whether or not the software involved uses SNI is much more variable.

DANE is a way to bind TLS certificates to domain names through DNS and DNSSEC. In particular it can be used to authenticate the SMTP connections used to deliver email (RFC 7672). When you use DANE with TLS over SMTP, using SNI is required and is also straightforward, because DNSSEC and DANE have told you (the software trying to deliver email over SMTP) what server name to use.

Recently, SNI came up on the Exim mailing list, where I learned that when it's sending email, Exim doesn't normally use SNI when establishing TLS over SMTP (unless it's using DANE). According to Exim developers on the mailing list, the reasons for this include not being sure of what TLS SNI name to use and uncertainties over whether SMTP servers would malfunction if given SNI information. This caused me to go look at our (Exim) logs for our incoming mail gateway, where I noticed that although we don't use DANE and don't have DNSSEC, a number of organizations sending email to us were using SNI when they established their TLS sessions (helpfully, Exim logs this information). In fact, the SNI information logged is more interesting than I expected.

We have a straightforward inbound mail situation; our domains have a single DNS MX record to a specific host name that has a direct DNS A record (IP address). Despite that, a small number of senders supplied wild SNI names of 'dummy' (which look like mostly spammers), a RFC 1918 IP address (a sendnode.com host), and the IP address of the inbound mail gateway (from barracuda.com). However, most sending mailers that used SNI at all provided our inbound mail gateway's host name as the SNI name.

Using yesterday's logs because it's easy, roughly 40% of the accepted messages were sent using SNI; a better number is that about 46% of the messages that used TLS at all were using SNI (roughly 84% of the accepted incoming messages used TLS). One reason the percentage of SNI is so high is that a lot of the SNI sources are large, well known organizations (often ones with a lot invested in email), including amazonses.com, outlook.com, google.com, quora.com, uber.com, mimecast.com, statuspage.io, sendgrid.net, and mailgun.net.

Given this list of organizations that are willing to use SNI when talking to what is effectively a random server on the Internet with nothing particularly special about its DNS setup, my assumption is that today, sending SNI when you set up TLS over SMTP doesn't hurt delivery very much. At the same time, that some people's software send bogus values suggests that fumbling the SNI name doesn't do too much harm, which is often unlike the situation with HTTPS.

PS: I suspect that the software setting 'dummy' as the SNI name isn't actually mail software, but is instead some dedicated spam sending software that's using a TLS library that has a default SNI name set and is (of course) not overriding the name, much as some web spider software doesn't specifically set the HTTP User-Agent and so inherits whatever vague User-Agent their HTTP library defaults to.

Spammers do forge various noreply@<you> sender addresses

It is probably not news to anyone reading this that some of the time, spammers sending you email will forge the email as being from various addresses at your domain, for either or both of the SMTP 'MAIL FROM' envelope sender address and the From: header address. Spammers have been doing this to us for years. What I hadn't realized until now, when I looked at the actual addresses being forged, was that spammers were forging various variations on 'noreply@<us>', in various variations of words and cases. Over the past ten days we've seen all of 'noreply@', 'Noreply@', 'Nonreply@', 'no_reply@', 'NOREPLY@', 'no-reply@', and 'NO-REPLY@'.

Of course, spammers also forge various plausible administrative addresses as well, such as 'Administrator@', 'Admin@', 'cpanel@', 'support@' (and 'Support@'), and one case of 'hr@', as well as the expected 'postmaster@'. These are almost all addresses that don't exist here and never have, so I'm pretty confident that spammers are just making them up instead of drawing them from a list of (past) legitimate email addresses of people here. I suspect that some or perhaps many of these forged addresses are being used on phish spams, and this is probably the case for the various 'noreply@' addresses.

(Spammers clearly use old email address lists to generate their envelope sender addresses, because we reject a lot lot of SMTP 'MAIL FROM' addresses that used to be real email addresses here but which have since been removed (we do eventually close some accounts). Interestingly, there is also a relatively frequently forged sender address that is a single-letter typo for a real person's email address.)

One of the lessons I draw from this little exercise in curiosity is that if we've created administrative-like email addresses in our system simply to reserve them, and we aren't using them, we should actively block their use as external sender addresses. If we want to create a dummy 'cpanel@' address, for example, we should definitely make it so that it's not accepted as a SMTP envelope sender.

(Because of some features of our mail environment, people here can created valid email addresses without our involvement (this has various entirely legitimate uses, including expendable personal email addresses). Historically this has meant that we grabbed a number of addresses simply as precautions to reserve them, without ever intending them to be 'legitimate'.)

PS: We do have a local noreply-like address, for internal use. However, spammers don't seem to forge it on their messages, perhaps because it basically never appears on email we send to actual people and thus has never made it onto various spammer lists of email addresses here.

(All of the email that we send to people has real sender and reply addresses that are read by us, even if the mail is sent by automated systems.)

A DKIM signature on email by itself means very little

In yesterday's entry on what I think the SMTP Smuggling attack enables, I casually said that you were safe if you ignored SPF results and only paid attention to DKIM. As sometimes happens, this was my thoughts eliding some important qualifications that I just take as given when talking about DKIM, but that I should spell out. The most important qualification is that a (valid) DKIM signature by itself means almost nothing, which is a bit unlike how SPF works.

First off, anyone can DKIM sign a message, provided that they control a bit of DNS (you could probably even do it in a mail client). Quite a lot of people, including spammers, can even DKIM sign email that is 'aligned' with the 'From:' header, which means that the DKIM signature is from the From: domain, not just from some random domain. A valid DKIM signature does provide definite attribution, and if it's for the From: domain, it more or less identifies who authorized the mail. Also, in practice lack of a DKIM signature is itself a signal, because an increasing number of places more or less require a DKIM signature, sometimes one that is from the From: domain.

(However, some people only have SPF records and this can be deliberately used to create email that can't be easily forwarded.)

A valid DKIM signature for the From: domain is at least as strong a sign as an SPF pass result. However, this doesn't mean that the email is any good, any more than an SPF pass does; spammers can and do pass both checks. Similarly, lack of a valid DKIM signature for the From: domain doesn't mean that it's not from that domain. To have some idea of that you need to check the domain's DMARC policy. In effect, the equivalent of SPF is the combination of DKIM and DMARC (or something like it).

So when I casually wrote about (only) paying attention to DKIM, I was implicitly thinking of using DKIM along with something else to tell you when DKIM results matter. This might be specific knowledge of which important domains you deal with DKIM sign their email (including your own domain), or it might mean checking DMARC, or both. And of course you can ignore both SPF and DKIM signatures, apart perhaps from logging DKIM results.

(We don't explicitly use DKIM signatures and DMARC in our Exim configuration, but these days we use rspamd for spam scoring and I think it makes some use of DKIM and perhaps DMARC.)

What I think the 'SMTP Smuggling' attack enables

The very brief summary of SEC Consult's "SMTP Smuggling" attack is that under the right circumstances, it allows you (the attacker) to cause one mail server to 'submit' an email with contents and SMTP envelope information that you provide to a second mail server. To the second email server, this smuggled email will appear to have come from the first mail server (because it did), and can inherit some of the authentication the first mail server has.

(It's important to understand that the actual vulnerability is in the second mail server, not the first one; the first one can and often must be completely RFC compliant in its behavior.)

The obvious authentication that the smuggled email inherits is SPF, because that's based on the combination of the sending IP (the first mail server) and the SMTP envelope sender (and possibly message From:), which is under your control. So you can put in a SMTP envelope sender (and a From:) that claims to be 'from' the first mail server, and the second mail server will accept it as authentic.

(An almost as obvious thing is that the smuggled email gets to share in whatever good reputation the sending email server has with the receiver. This is most useful if you can get a big, high reputation mail system to be the first server, which is possible (or perhaps 'was' by the time you're reading this).)

If you forge email as being from something that has a DMARC policy that passes the policy if SPF passes, you can also get your forged email to pass DMARC checks. The same is true if the second email server happens to be something that imposes its own implicit DMARC-like policy that accepts email if SPF passes and (and possibly that SPF is 'aligned' with the From: message address).

What you can't fully do is inherit DKIM authentication. You can add your own valid DKIM headers to your smuggled email, but you can only do this for domains with DNS under your control (or domains where you've managed to obtain the DKIM signing keys). This probably doesn't include the first email server and its domain, and because the first email server doesn't recognize your smuggled email as an actual email message, it won't DKIM sign the email for you. The only way you can get the domain of the first email server to DKIM sign your second email for you is if the second email server is also an internal one belonging to the same domain and it will DKIM sign outgoing messages. This general configuration is reasonably common (incoming and outgoing email servers are often different), but usually they run the same mail software and so they won't have the different interpretations of the email message(s) that SMTP Smuggling needs.

The result of this is that if the second (receiving) email server doesn't check SPF results and only pays attention to DKIM (which is increasingly mandatory in practice), it's almost completely safe from SMTP Smuggling even if it accepts things other than 'CR LF . CR LF' as the email message terminator. Since SPF breaks things (also), this is what I feel you should already be doing.

The (historical) background of 'SMTP Smuggling'

The recent email news is SEC Consult's SMTP Smuggling - Spoofing E-Mails Worldwide (via), which I had a reaction to. I found the article's explanation of SMTP Smuggling a little hard to follow, so for reasons that don't fit within the scope of today's entry, I'm going to re-explain the central issue in my own way.

SMTP is a very old Internet protocol, and like a variety of old Internet protocols it has what is now an odd and unusual core model. Without extensions, everything in SMTP is line based, with the sender and receiver exchanging a series of 7-bit ASCII lines for commands, command responses, and the actual email messages (which are sent as a block of text in the 'DATA' phase, ie after the sender has sent a 'DATA' SMTP command and the receiver has accepted it). Since SMTP is line based, email messages are also considered to be a series of lines, although the contents of those lines is (mostly) not interpreted. SMTP needs to signal the end of the email text being transmitted, and as a line based protocol it does this by a special marker line; a '.' on a line by itself marks the end of the message.

(In theory there's a defined quoting and de-quoting process if an actual line of the message starts with a '.'; see RFC 821 section 4.5.2, which is still there basically intact in RFC 5321 section 4.5.2. In practice, actual mailer behavior has historically varied.)

When you have a line based protocol you must decide how the end of lines are marked (the line terminator). In SMTP, the official line terminator is the two byte (two octet) sequence 'CR LF', because this was the fashion at the time. This includes the lines that are part of the email message that is sent in the DATA phase, and so the last five octets sent at the end of a standard compliant SMTP message are 'CR LF . CR LF'. The first 'CR LF' is the end of the last line of the actual message, and then '. CR LF' makes up the '.' on a line by itself.

(This means that all lines of the message itself are supposed to be terminated with 'CR LF', regardless of whatever the native line terminator is for the systems involved. If you're doing SMTP properly, you can't just blast out or read in the raw bytes of the message, even apart from RFC 5321 section 4.5.2 concerns. There are various ESMTP extensions that can change this.)

Unfortunately, SMTP's definition makes life quite inconvenient for systems that don't use CR LF as their native line ending, such as Unix (which uses just LF, \n). Because SMTP considers the email message itself to be a sequence of lines (and there's a line length limit), a Unix SMTP mailer has to keep translating all of the lines in every email message it sends or receives back and forth between lines ending in \n (the native format) and \r\n (the SMTP wire format). Doing this translation raises various questions about what you should send if you encounter a \r (or a \r\n) in a message as you send it, or encounter a bare \n (or \r) in a message as you receive it. It also invites shortcuts, such as turning \r\n into \n as you read data and then dealing with everything as Unix lines.

Partly for this reason and partly because CR LF line endings make various people grumpy, there has been somewhat of a tradition of mailers accepting other things as line endings in SMTP, not just CR LF. Historically a variety of Unix mailers accepted just LF, and I believe that some mailers have accepted just CR. Even today, finding SMTP listeners that absolutely require 'CR LF' as the line ending on SMTP commands isn't entirely common (GMail's SMTP listener doesn't, for example, although possibly this will cause it to be unhappy with your email, and I haven't tested its behavior for message bodies). As a result, such mailers can accept things other than 'CR LF . CR LF' as the SMTP DATA phase message terminator. Exactly what a mailer accepts can vary depending on how it implemented things.

(For instance, a mailer might turn '\r\n' into '\n' and accept '\n' as a line terminator, but only after checking for a line that was an explicit '. CR LF'. Then you could end messages with 'LF . CR LF', without the initial 'CR'; the bare LF would be taken as the line terminator for the last data line, then you have the '. CR LF' of the official terminator sequence. But if you sent 'LF . LF', that wouldn't be recognized as the message terminator.)

This leads to the core of SMTP Smuggling, which is embedding an improper SMTP message termination in an email message (for example, 'LF . LF'), then after it adding SMTP commands and message data to submit another message (the smuggled message). To make this do anything useful we need to find a SMTP server that will accept our message with the embedded improper terminator, then send the whole thing to another mail server that will treat the improper terminator as a real terminator, splitting what was one message into two, sent one after the other. The second mail server will see the additional mail message as coming from the first mail server, although it really came from us, and this may allow us to forge message data that we couldn't otherwise.

(There are various requirements to make this work; for example, the second mail server has to accept being handed a whole block of SMTP commands all at once. These days this is a fairly common thing due to an ESMTP extension for 'pipelining', and also because SMTP receivers have to do extra work to detect and reject getting handed a block of stuff like this. See the original article for the gory details and an extended discussion.)

What you can do with SMTP Smuggling in practice has some limitations and qualifications, but that's for another entry.

The various meanings of DKIM signing message headers

When I talked about the issue of what headers to include in email DKIM signatures, I didn't really cover the specifics of how you DKIM sign email headers and what the various options mean. The specifics can matter, especially since they help you (me) understand and navigate through the options that mailers (such as Exim) offer here.

In email messages, DKIM signatures appear in a DKIM-Signature header, which lists a bunch of parameters:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed;
   d=list.zfsonlinux.org;
   h=from:to:subject:message-id:in-reply-to:references:date
   [....]

The 'h=' list (which isn't complete here) is a list of headers that have been signed. More specifically, it's a list of instances of headers. If there are multiple instances of a given header in a message, DKIM defines an order to them and the instances of the header are checked (or used) in that order. So if you include 'from' once in the DKIM header list, you are saying that your DKIM signature includes DKIM's first 'From:' header in the message. If a second 'From:' header is added to the message, it's not included what's covered by your DKIM signature; it can have any value and the message will still pass DKIM validation.

As mentioned last time, including a header that doesn't exist in the DKIM signature signs its absence; if that header is then added to the message, the DKIM signature will become invalid. DKIM signing things that aren't there is sometimes called oversigning a header; you're not just signing what's present, you're also signing what's not. As a corollary of this, if you want to seal a message against having extra copies of some headers added, you can deliberately oversign existing headers. This is done by including their names an extra time in the h= list; the first time signs the existing header, and the second time signs that there's no second header. So if we wanted to make sure no one added a second 'From:' to a message, we'd sign 'h=from:from:[....]'.

One reason to oversign existing headers that should only appear once is that anyone who adds a second 'From:', 'Date:' or whatever to your message is probably up to no good. Another reason is that it's hard to predict which instance of the header a mail client will show to people reading the message, and there are probably some mail clients that will show the wrong instance of the header (the instance that isn't covered by your DKIM signature and so can be set to anything by an attacker).

This creates several options and decisions:

• do you make it so that certain headers can't be added to the message later, like the List-* and Resent-* families, or allow them to be added later?
• what headers do you sign if they're present? For example, should you sign Resent-* or List-* headers at all?
• do you oversign some existing headers so that no additional copies can be added?

Based on a quick skim of email that I have handy, relatively few sources of mail seem to be oversigning existing headers. However, GMail does oversign at least some email for core headers like From: and Subject:. Since Google is one of the eight hundred pound gorillas of email, if they're doing it people's DKIM signature validation is at least prepared to cope with this.

(I suspect that having two From:, Subject:, or so on headers trips enough spam detection systems that attackers don't normally do it.)