I know it's possible to have a wildcard as a hostname in the SAN of a certificate, like *.example.com. However, can you put *-test.example.com in the SAN? I found out you can't put that in DNS even though I couldn't find anything on that, so I'm wondering whether you could put it in the SAN.
Thanks, Dallas, I somehow missed that Wikipedia page.
I think the killer for this is: "As of 2011, partial wildcard support is optional, and is explicitly disallowed in SubjectAltName headers that are required for multi-name certificates.", but also: "All major browsers have deliberately removed support for partial-wildcard certificates;[12][13] they will result in a "SSL_ERROR_BAD_CERT_DOMAIN" error."
So, it's a no-no.
Related
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"
There's a pub in my town whereby, if you sign up to their newsletter using their website and provide a "unique" email address, you get a free drink. On a whim, I decided to sign up a second time using myemail+one#gmail.com. It let me. I'm now sitting on a nice comfy pile of free drink vouchers.
This got me thinking about a system we have here, where the email address is considered the unique identifier. Checking the code, sure enough, if we were offering vouchers in our business, someone else would be sitting pretty.
The basic, stab-in-the-dark, fix is to check for the "+" character and ignore everything after it (up to the #), and compare using that. But I am unsure if this was the intent for the + character. Would that work?
Secondly, are there any other caveats that would allow a user to sign up multiple times with a seemingly different email address, but which actually would always end up in the same mailbox?
This question is language-agnostic.
While using a plus sign as an e-mail address alias is a known feature of gmail, other mailers do either not allow it or use a minus sign instead. '+' is a legitimate character to be used as part of an email address according to the RFC.
The use of '.' is also a gray area. john.doe#gmail.com and johndoe#gmail.com send also both to the same email address and look different.
In order to validate the uniqueness of an email address you will have to prepare a rule base for your application, keep it up to date and still expect surprises...
In my application I have URIs that include the userid to identify user private resources. And userids are emails, for example:
/users/user2#example.com/private-resource
It's a good practice to put email in the URI, including characters like . and #?
Or should I use some other type of userid? Like an hash for example?
If the email can function as fixed identifier it would be ok.
The thing is that most of the time applications will allow users to change emails; in this case it would be more bullet proof to control the ID-space yourself, e.g. by using a surrogate key. (Because the email (if users can change them) is not the identity but merely a property of the resource).
Another argument against emails is - as #Rob points out - a potential security issue.
There's no problem with that... just make sure you URL-encode the appropriate characters.
(Email's kind of sensitive information, though, you might want to pass a hash or surrogate key instead just to protect your users' email addresses if the URLs get passed around.)
though having '-' in uri is absolutely fine.
use of '#' , '#' are discouraged
however, as long as email id is an id e.g. http://example.org/user/mail/{email}/1234
guess thats fine.
We are using the following validation code to check for a valid email address formatting on a web form driving by Lotus Notes:
#If((#ValidateInternetAddress([Address821]; #ThisValue)!=""
| #Contains(#ThisValue; "\"") | #Contains(#ThisValue; "'")
| #Contains(#ThisValue; " ")); "Please include a valid email address."; "");
Currently, if a user enters any of the following inputs, the verification throws the error message:
empty field
" ", ', or / character
the domain portion of the email: "test.com"
only #
However, if a user enters test#test the form validates this as a valid email address format.
Is this format considered to be a valid "Address821" format? Or is the form validating an incorrect format as a valid email address?
Yes, it technically is valid address syntax, both by past and current standards.
The language in the RFC's has evolved over time:
RFC-821: 3.7. DOMAINS
Domains are a recently introduced concept in the ARPA Internet mail
system. The use of domains changes the address space from a flat
global space of simple character string host names to a hierarchically
structured rooted tree of global addresses. The host name is replaced
by a domain and host designator which is a sequence of domain element
strings separated by periods with the understanding that the domain
elements are ordered from the most specific to the most general.
This isn't very precise. It doesn't explicitly say that there must be more than one element in the domain name, but it doesn't explicitly prohibit it either. But this was obsoleted by:
RFC-2821: 2.3.5 Domain
A domain (or domain name) consists of one or more dot-separated
components.
...
The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
This seems to be saying that it's illegal, but actually it isn't saying that. I'll explain below, but first let's have a look at the draft standard that is intended to obsolete 2821, and which clarifies things a great deal:
RFC-5321 2.3.5 Domain Names
A domain name (or often just a "domain") consists of one or more components, separated by dots if more than one appears. In the case of a top-level domain used by itself in an email address, a single string is used without any dots. This makes the requirement, described in more detail below, that only fully-qualified domain names appear in SMTP transactions on the public Internet, particularly important where top-level domains are involved.
...
The domain name, as described in this document and in RFC 1035 [2], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
What this makes clear is that no dot is required in a domain name, as long as it is a top level domain.
#ValidateInternetAddress cannot reasonably know whether "test" is a valid top level domain. Even if IBM programmed in the list of approved public TLD's (which IMHO would be a bad idea since it can and does change), you can in fact set up a private TLD called "test" in your own DNS. That's not the same thing as a "local alias" which the standard does prohibit. There's no rule against actual TLDs.
And for that matter, it could even be a public TLD. Theoretically, the owner of a TLD could set up a mail server for the TLD. I.e., President#US, or Queen#UK. Not likely, but possible in those cases, but with all the new TLD's coming on line, I wouldn't be surprised if some of the registrars are using info#domain.
I guess theoretically #ValidateInternetAddress could make the DNS call to check whether it can resolve "test" as a TLD, but the doc for that function only says that it checks the syntax of the address, and the existence of the TLD is a semantic issue, not a syntax issue.
I am working on a more complete email validator in java and came across an interesting ability to embed comments within an email both in the "username" and "address" portions.
The following snippet from http://www.dominicsayers.com/isemail/ has this to say about comments within an email.
Comments are text surrounded by parentheses (like these). These are OK but don't form part of the address. In other words mail sent to first.last#example.com will go to the same place as first(a).last(b)#example(c).com(d). Strange but true.
Do emails like this really exist ?
Is it possible to form hosts like this ?
I tried entering an url such as "google(ignore).com" but firefox and some other browsers failed and i was wondering is this because its it wrong or is it because they dont know about host name comments ?
That syntax -- comments within an addr-spec -- was indeed permissible by the original email RFC, RFC 822. However, the placement of comments like you'd like to use them was deprecated when that RFC was revised by RFC 2822... 10 years ago. It's still marked as obsolete in the current version, RFC 5322. There's no good excuse for emitting anything using that syntax.
Address parsers are supposed to be backwards-compatible in order to cover all conceivable cases, including 10-years-deprecated bits like the one you're trying to take advantage of here. But I'll bet that many, many receiving mail agents will fail to properly parse out those comments. So even though you may have technically found a loophole via the "obsolete addressing" section of the RFC, it's not likely to do you much good in practice.
As for HTTP, the syntax rules aren't the same as email syntax rules. As you're seeing, the comment section from RFC 822 isn't applicable.
Just because you can do it in the spec, doesn't mean that you should. For example, Gmail will not accept that comment format for address.
Second, (to your last point), paren-comments being allowed in email addresses doesn't mean that they work for URLs.
Finally, my advice: I'd tailor the completeness of your validator to your requirements. If you're writing a new MTA (mail transfer agent), you'll probably have to do it all. If you're writing a validator for a user input, keep it simple:
look for one #,
make sure you have stuff before (username) and after (domain name),
make sure you have a "dot" in the hostname string,
[extra credit] do a DNS lookup of the hostname to make sure it resolves.