Difference between revisions of "Email/OpenDKIM"

From WhyAskWhy.org Wiki
Jump to: navigation, search
m (More links, rearranged some content)
m (Added Author Domain Signing Policy info.)
Line 3: Line 3:
 
[[Category:Server]]
 
[[Category:Server]]
 
[[Category:Email]]
 
[[Category:Email]]
 +
 +
== Sort me ==
 +
 +
Unix and Linux System Administration Handbook: Edition 4
 +
<blockquote>
 +
RFC5617 defines a TXT record you can stash in a special subdomain to express your overall policy with respect to signing messages. This record was just recently standardized (2009) and is called an ADSP (Author Domain Signing Policy) text record. The subdomain is _adsp._domainkey.domain.
 +
 +
Inside the TXT record, you include a dkim= clause to declare your site’s signing policy. The possible values are
 +
 +
* all, for domains that sign all outgoing email messages
 +
* unknown, for domains that might sign some email messages
 +
* discardable, for domains that sign all email and recommend that recipients discard messages whose signature cannot be verified
 +
 +
As an example, the discardable tag might be used by a bank that sends sensitive customer account information from a subdomain created for this purpose. A user’s acting on instructions from forged email that appears to emanate from this domain could have disastrous consequences, so it’s best if such email can be refused or discarded without reaching the addressee. The ADSP TXT record can also include a t=y clause if you are just testing out DKIM and don’t want recipients to take your signatures too seriously. During the development of the ADSP system, prior to RFC5617, a domain’s ADSP TXT record was kept in a different subdomain (_domainkey.domain, with no _adsp prefix) and had a slightly different syntax. o=~ meant that the domain signed some of its email, and o=- meant that it signed all email.
 +
 +
Since the two conventions use different subdomains, they can coexist. As of this writing, the original form remains predominant. If you are serious about getting recipients to scrutinize your signatures, it’s probably best to use both conventions for the next few years until everyone has become RFC5617-compliant. <ref name="opendkim-book-unix-and-linux-system-administration" />
 +
</blockquote>
  
 
== References ==
 
== References ==
 +
 +
<references>
 +
 +
<ref name="opendkim-book-unix-and-linux-system-administration">[[informit:9780131480056|UNIX and Linux System Administration Handbook, 4th Edition]]</ref>
 +
 +
 +
</references>
  
 
=== Official ===
 
=== Official ===

Revision as of 22:24, 23 February 2014


Sort me

Unix and Linux System Administration Handbook: Edition 4

RFC5617 defines a TXT record you can stash in a special subdomain to express your overall policy with respect to signing messages. This record was just recently standardized (2009) and is called an ADSP (Author Domain Signing Policy) text record. The subdomain is _adsp._domainkey.domain.

Inside the TXT record, you include a dkim= clause to declare your site’s signing policy. The possible values are

  • all, for domains that sign all outgoing email messages
  • unknown, for domains that might sign some email messages
  • discardable, for domains that sign all email and recommend that recipients discard messages whose signature cannot be verified

As an example, the discardable tag might be used by a bank that sends sensitive customer account information from a subdomain created for this purpose. A user’s acting on instructions from forged email that appears to emanate from this domain could have disastrous consequences, so it’s best if such email can be refused or discarded without reaching the addressee. The ADSP TXT record can also include a t=y clause if you are just testing out DKIM and don’t want recipients to take your signatures too seriously. During the development of the ADSP system, prior to RFC5617, a domain’s ADSP TXT record was kept in a different subdomain (_domainkey.domain, with no _adsp prefix) and had a slightly different syntax. o=~ meant that the domain signed some of its email, and o=- meant that it signed all email.

Since the two conventions use different subdomains, they can coexist. As of this writing, the original form remains predominant. If you are serious about getting recipients to scrutinize your signatures, it’s probably best to use both conventions for the next few years until everyone has become RFC5617-compliant. [1]

References

Official


Guides


Unsorted


Diagnostics