I want to set OpenDMARC to support multiple domains and only show the header for the domain sending the email.
Adding more than one AuthservID doesn't do it. the header shows as
Authentication-Results: domain1.com; dmarc=none header.from=domain2.com
You are misunderstanding the syntax of the Authentication-Results: header.
The first field, in your case domain1.com, is essentially a site ID for the service that performed authentication verification. Different sites do this slightly differently, but it is not intended to correlate to the recipient domain. It is intended to identify who performed authentication validation. Yahoo, for example, puts specific hostnames in that field, such as mta1315.mail.gq1.yahoo.com. Google and Hotmail both just use more generic mx.google.com and hotmail.com identifiers respectively.
Refer to section 2.4 of RFC 7001 "Message Header Field for Indicating Message Authentication Status" (https://www.rfc-editor.org/rfc/rfc7001#page-13) for full details.
Only the SPF and DKIM identifiers - domain2.com in your example above - or each instance of agari.com in my example below:
Authentication-Results: mx.google.com; spf=pass (google.com: domain of chris#agari.com designates 2607:f8b0:400e:c03::22b as permitted sender) smtp.mail=chris#agari.com; dkim=pass header.i=#agari.com; dmarc=pass (p=REJECT dis=NONE) header.from=agari.com
relate to the recipient domain. Note that because our email is hosted with google apps, the identifier is mx.google.com, telling me who validated email authentication.
I would recommend configuring AuthservID to a value that represents either the machine that performed authentication, or perhaps an organizational name or identifier if appropriate for your site.
Related
I'm trying to figure out how DKIM verification works.
My understanding so far has been that the domain inside DKIM-Signature header must match the domain inside From header in case for DKIM check to pass.
I configured the opendkim SigningTable all e-mails from lskdfjlsd.com domain with domain key from different domain:
*#lskdfjlsd.com default._domainkey.unrelateddomain.com
My KeyTable looks like this:
default._domainkey.unrelateddomain.com unrelateddomain.com:default:/etc/opendkim/keys/unrelateddomain.com/default
I send out e-mails with this:
echo "Hello world" | mail -s "Hello" -r noreply#lskdfjlsd.com my-personal-mail#gmail.com
When I check the e-mail inside my-personal-mail#gmail.com I can see the DKIM check passed for the domain unrelateddomain.com - the content of the DKIM header and From field is:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelateddomain.com; s=default
From: noreply#lskdfjlsd.com
And this is where my confusion stems from. The DKIM check says PASS for domain unrelateddomain.com but the From header clearly says it's originated from different domain. Based on this the https://mxtoolbox.com/dmarc/dkim/dkim-alignment I'd expect the DKIM check will fail.
I've tried to playing with domains and DKIM check always says PASS no mather if domains match or not.
The domain mentioned in the d= tag of the signature header tells the receiving server where to look for the public key to use, in the selector record. The s= tag tells it the name of the selector. The DKIM RFC does not require the FROM domain to be the same domain as the DKIM signature domain.
In fact, a message can be signed by multiple signatures from multiple domains, and often is. For example, a service like MailGun might add a DKIM signature for their domain, while enabling you to set up an additional DKIM signture for the domain you're sending From.
This is exactly why DMARC has been introduced, to require alignment between domains used in authentication technologies (SPF and DKIM) and the domain used in the FROM header. Because that is the main address shown in the email client facing the user.
I have a question related to Share cookie between subdomain and domain - what would happen if I set the domain while setting cookie as .com? Would the cookie be available to all .com websites?
Well-configured user-agents should reject such cookies, as explained in RFC 6265 section 5.3:
If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix:
If the domain-attribute is identical to the canonicalized request-host:
Let the domain-attribute be the empty string.
Otherwise:
Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an
up-to-date public suffix list, such as the one maintained by
the Mozilla project at http://publicsuffix.org/.
I've recently found something that questions everything I thought I knew about TLS.
This website https://int.lyve-lyon.alpha.grandlyon.com is secured with TLS but the certificate is actually issued to rec.lyve-lyon.alpha.grandlyon.com.
How can the server submit a certificate issued for a different host, and how can the browser not throw a TLS error? It looks like the certificate behaves like a wildcard one and I cannot understand why.
Subject Alternative Name (SAN) is an extension to X.509 that allows
various values to be associated with a security certificate using a
subjectAltName field. These values are called Subject Alternative
Names (SANs). Names include:
Email addresses
IP addresses
URIs
DNS names (this is usually also provided as the Common Name RDN within the Subject field of the main certificate.)
directory names (alternative Distinguished Names to that given in the Subject)
other names, given as a General Name: a registered[3] object identifier followed by a value
from https://en.wikipedia.org/wiki/Subject_Alternative_Name
I'm setting up basic authentication on a php site and found this page on the php manual showing the set up. What does "realm" mean here in the header?
header('WWW-Authenticate: Basic realm="My Realm"');
Is it the page page being requested?
From RFC 1945 (HTTP/1.0) and RFC 2617 (HTTP Authentication referenced by HTTP/1.1)
The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL of the
server being accessed, defines the protection space. These realms
allow the protected resources on a server to be partitioned into a set
of protection spaces, each with its own authentication scheme and/or
authorization database. The realm value is a string, generally
assigned by the origin server, which may have additional semantics
specific to the authentication scheme.
In short, pages in the same realm should share credentials. If your credentials work for a page with the realm "My Realm", it should be assumed that the same username and password combination should work for another page with the same realm.
A realm can be seen as an area (not a particular page, it could be a group of pages) for which the credentials are used; this is also the string that will be shown when the browser pops up the login window, e.g.
Please enter your username and password for <realm name>:
When the realm changes, the browser may show another popup window if it doesn't have credentials for that particular realm.
According to the RFC 7235, the realm parameter is reserved for defining protection spaces (set of pages or resources where credentials are required) and it's used by the authentication schemes to indicate a scope of protection.
For more details, see the quote below (the highlights are not present in the RFC):
2.2. Protection Space (Realm)
The "realm" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection.
A protection space is defined by the canonical root URI (the scheme
and authority components of the effective request URI)
of the server being accessed, in combination with
the realm value if present. These realms allow the protected
resources on a server to be partitioned into a set of protection
spaces, each with its own authentication scheme and/or authorization
database. The realm value is a string, generally assigned by the
origin server, that can have additional semantics specific to the
authentication scheme. Note that a response can have multiple
challenges with the same auth-scheme but with different realms. [...]
Note 1: The framework for HTTP authentication is currently defined by the RFC 7235, which updates the RFC 2617 and makes the RFC 2616 obsolete.
Note 2: The realm parameter is no longer always required on challenges.
I have a dev server in our office that is behind the firewall. The hostname is franklin. We name all our servers after scientists or inventors.
When I set an HTTP cookie:
Set-Cookie: user=kenny; expires=1245424860.11; Path=/; domain=franklin
The cookie doesn't set. I have tried the following with no luck.
.franklin
.franklin.local
franklin.local
.franklin.localdomain
franklin.localdomain
Do I have to set the hostname to something different or can I set this cookie through some magic I don't know already?
RFC 2109 says:
To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if any of the
following is true:
The value for the Domain attribute contains no embedded dots or
does not start with a dot.
The value for the request-host does not domain-match the Domain
attribute.
And also:
Domain Defaults to the request-host.
If your host is franklin:
Cookies with domain=.franklin will be rejected, because it has no embedded dot.
Cookies with domain=.franklin.local will be rejected, because it does not match the actual host name of your server.
The solution is to rename your hostname to franklin.local or franklin.<tld> and set the domain attribute of the cookie accordingly (domain=.franklin.<tld>). Alternatively (as you found out), do not specify the domain, and let the user agent fallback to the request host.
Are you setting the cookie from the right domain? You should access the website over http://franklin/ otherwise it wouldn't work (see: same origin policy).