Unable to setup DKIM TXT-Value as DNS-Record

Unable to setup DKIM TXT-Value as DNS-Record - google-apps

I have a domain name which DNS is edited via Google Cloud DNS. And I have a Google Apps for Work Account with that domain name.
I wanted to set up DKIM-authentication but when I try to save the corresponding TXT-Record I get the error that the Tag is invalid.
I did the same before and it worked perfectly. I checked the old setup and I saw that the old DKIM-record was about half the length. The new one seems to be too long for a TXT-record in the Google Cloud Platform.
Does anyone have a solution?

yeah, you have to split the record as described in this article:
https://support.google.com/a/answer/173535
If your domain provider limits the size of the TXT record value to 255 characters, you can't enter the DKIM key as a single entry in the DNS records. In this case, split the key into multiple quoted text strings and enter them together in the TXT record value field. For example, split the DKIM key into two parts as follows:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAraC3pqvqTkAfXhUn7Kn3JUNMwDkZ65ftwXH58anno/bElnTDAd/idk8kWpslrQIMsvVKAe+mvmBEnpXzJL+0LgTNVTQctUujyilWvcONRd/z37I34y6WUIbFn4ytkzkdoVmeTt32f5LxegfYP4P/w7QGN1mOcnE2Qd5SKIZv3Ia1p9d6uCaVGI8brE/7zM5c/" "zMthVPE2WZKA28+QomQDH7ludLGhXGxpc7kZZCoB5lQiP0o07Ful33fcED73BS9Bt1SNhnrs5v7oq1pIab0LEtHsFHAZmGJDjybPA7OWWaV3L814r/JfU2NK1eNu9xYJwA8YW7WosL45CSkyp4QeQIDAQAB"
The two quoted strings have to stay on the same line - in the same box in the Cloud DNS interface rather than in two separate boxes.

I just ran into the same issue.
The google DKIM keys text strings are longer than most other DKIM keys (probably higher bit count) and won't fit into the 255 length limitation per TXT field.
The way to get around this is to do two TXT entries and end the first with a \ or use ( in the first and ) in the second.
The google cloud DNS parser seems to not allow a trialing \ and ) or preceding (.
There may be some way to escape it on the Google Cloud DNS tool - but it is not obvious.
Ok I have a solution.
Make sure to only do 1 TXT record entry and not add multiple TXT records - this is the key step.
If you click "Add Item" when setting up the TXT record this actually creates another TXT record and both records may resolve in any order and the DKIM won't validate.
The trick is to make sure to place the broken up strings into the first text input only and break them into small enough pieces that they all get parsed in the correct sequential order.

Select bit length "1024" while generating DKIM records at Gsuite Admin console. This worked for me.

How to easily add DKIM as TXT in GCP Cloud DNS:
copy/paste the entire DKIM string into the TXT field
ignore the ...this domain has whitespace but is not a quoted string... related GCP warning you may see
before you save it, insert a single space in the middle of the DKIM p= value string.
That's it.
This approach was tested with Mailgun and a domain name configured in Google Cloud DNS.
Additional notes:
GCP will automatically add double quotes around each space separated string after you save
you need to separate the p= string in such a way so that no resulting double quoted string created after you save is longer than 255 characters
example (before):
k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82yBC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB
example (after):
k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82y BC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB
Scroll to the right and you'll see the newly added space - this produces three space separated strings, each less than 255 characters:
k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82y
BC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB
example (after, viewed via DIG):
;; ANSWER SECTION:
dkim.example.com. 300 IN TXT "k=rsa;" "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmCLrt5j82y" "BC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB"
Ref:
DKIM TXT record value invalid, cloud-dns-discuss group message

The solution that worked for me with Google Cloud DNS was to use the tool on this web page to "fix" the Mailgun provided DKIM string:
https://www.mailhardener.com/tools/dns-record-splitter
More detail: How to enter TXT values in Google Cloud DNS
https://www.mailhardener.com/blog/how-to-enter-txt-values-in-google-cloud-dns

Just add first txt k=rsa; p=abc in DNS record and ignore warnings. then add the rest. This works for me. Tested on mailgun+Gcloud

Related

Email IDNA encoding. Do we need to encode the whole email or each parts separately?

I have an email with accents that needs to be encoded using IDNA (from Python)
Something like this:
CäciliaAbitz#somedomain.net
If I do a encode('idna') for the whole email, I get the following:
xn--cciliaabitz#somedomain-04b.net
The domains became somedomain-04b.net, which is not normal (right?)
Doing a encoding on each part of the email results in :
b''.join([x.encode('idna') for x in email.split('#')])
> b'xn--cciliaabitz-l8a#somedomain.net'
But I'm not sure if this is correct, working or if I'm missing something.

RFC 5890 works on labels, which are mostly dot separated parts of an email address. In your example, you only have one label in the local part (before the # sign), "CäciliaAbitz", and two labels in the domain part ("somedomain.net"). If you encode without paying attention to the labels, you encode the dots, and the result is a single label where you need multiple ones. With that, your assumption, that "somedomain-04b.net" is not normal (or valid), is correct.
To correctly encode, you need to split not only between local and domain part at the #, but also at any dot within both local and domain parts.

Mozilla ThunderBird setHeader(hdr,val) strips multiple spaces

I am developing an addon for Mozilla Thunderbird, and I need to set a custom header on outgoing emails. I have noticed an anomaly in the way headers are set.
The call: gMsgCompose.compFields.setHeader('x-test', 'multiple spaces');
will set the x-test header to: multiple spaces - notice how the double spaces were transformed into a single space.
My addon depends on being able to retrieve the exact value, including double spaces. It is not an option to replace double spaces with something else. How can I make Thunderbird stop this transformation? Is the source code available somewhere so I can examine why and how this happens? I suspect the problem might lie with how line folding is implemented.
Cheers.

It's a feature, apparently. Here is the source code in question. This is to comply with RFC-2047 about replacing linear-white-spaces with a single space.
So I guess Thunderbird does as its supposed to, and I have to find another way around that limitation.

Exchange Server Transport Rule Failing Emails From .mil

I am using Exchange Server 2013 and have many transport rules set up to filter out emails from most countries outside of the US.
We recently received an email from a military email, ending in .mil
The email was blocked by my transport rules but does not match any of the extensions I have listed. Except for possibly one! I have an extension to block '.il$'. So this should block ALL emails that end with ".il". However, if the transport rules use true regular expression rules, the "." would be a wildchar and match any and every character including a "." itself. Is this the cause of my issue? I do not have a .mil email account to test with or I could check myself. I have added a character escape to my transport rule, making it '\.il$' hoping that it will fix this.
I read everything I can find about the regex rules for Exchange's Transport Rules, and I cannot find anything that mentions you must escape the dot. Maybe this is just a rare issue and they didn't foresee it occurring?
One of the documents I have read: https://technet.microsoft.com/en-us/library/aa997187(v=exchg.141).aspx

Long story short: YES, the dot(.) must be escaped with a \. Otherwise it is a single wildchar that matches any character [A-Z a-z 0-9 . , /] etc. just like in regular expression. I assume that Microsoft is using every rule from regular expression for the transport rules but do not quote me on that.
This cannot be found in any documentation that I have researched, it also seems that every example that I have looked at on the web has been doing it wrong as well. Examples that I see are always ".com$" will block all emails from a sender ending in .com. This is true because the dot can also be a dot. But this will also block any emails that end in "ecom" for example, which may be an issue if they ever decide to release such extension.
Sorry for answering my own question, but I want this to be here for future reference since it can't seem to be found anywhere else.

Are email addresses allowed to contain non-alphanumeric characters?

I'm building a website using Django. The website could have a significant number of users from non-English speaking countries.
I just want to know if there are any technical restrictions on what types of characters an email address could contain.
Are email addresses only allowed to contain English letters, numbers, _, # and .?
Are they allowed to contain non-English alphabets like é or ü?
Are they allowed to contain Chinese or Japanese or other Unicode characters?

Email address consists of two parts local before # and domain that goes after.
Rules to these parts are different:
For local part you can use ASCII:
Latin letters A - Z a - z
digits 0 - 9
special characters !#$%&'*+-/=?^_`{|}~
dot ., that it is not first or last, and not in sequence
space and "(),:;<>#[] characters are allowed with restrictions (they are only allowed inside a quoted string, a backslash or double-quote must be preceded by a backslash)
Plus since 2012 you can use international characters above U+007F, encoded as UTF-8.
Domain part is more restricted:
Latin letters A - Z a - z
digits 0 - 9
hyphen -, that is not first or last, multiple hyphens in sequence are allowed.
Regex to validate
^(([^<>()\[\]\.,;:\s#\"]+(\.[^<>()\[\]\.,;:\s#\"]+)*)|(\".+\"))#(([^<>()[\]\.,;:\s#\"]+\.)+[^<>()[\]\.,;:\s#\"]{2,})
Hope this saves you some time.

Well, yes. Read (at least) this article from Wikipedia.
I live in Argentina and here are allowed emails like ñoñó1234#server.com

The allowed syntax in an email address is described in [RFC 3696][1], and is pretty involved.
The exact rule [for local part; the part before the '#'] is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character
[...]
Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
[...]
Any characters, or combination of bits (as octets), are permitted in
DNS names. However, there is a preferred form that is required by
most applications...
...and so on, in some depth.
[1]: https://www.rfc-editor.org/rfc/rfc3696

Instead of worrying about what email addresses can and can't contain, which you really don't care about, test whether your setup can send them email or not—this is what you really care about! This means actually sending a verification email.
Otherwise, you can't catch a much more common case of accidental typos that stay within any character set you devise. (Quick: is random#mydomain.com a valid address for me to use at your site, or not?) It also avoids unnecessarily and gratuitously alienating any users when you tell them their perfectly valid and correct address is wrong. You still may not be able to process some addresses (this is necessary alienation), as the other answers say: email address processing isn't trivial; but that's something they need to find out if they want to provide you with an email address!
All you should check is that the user supplies some text before an #, some text after it, and the address isn't outrageously long (say 1000 characters). If you want to provide a warning ("this looks like trouble! is there a typo? double-check before continuing"), that's fine, but it shouldn't block the add-email-address process.
Of course, if you don't care to ever send email to them, then just take whatever they enter. For example, the address might solely be used for Gravatar, but Gravatar verifies all email addresses anyway.

There is a possibility to have non-ASCII email addresses, as shown by this RFC: https://www.rfc-editor.org/rfc/rfc3490 but I think this has not been set for all countries, and from what I understand only one language code will be allowed for each country, and there is also a way to turn it into ASCII, but that won't be a trivial issue.

I have encountered email addresses with single quotes, and not infrequently either. We reject whitespace (though strictly speaking it is allowed), more than one '#' sign and address strings shorter than five characters in total. I believe this solves more problems than it creates, and so far over ten years and several hundred thousand addresses it's worked to reject many garbage addresses. Also there is a trigger to downcase all email addresses on insert or update.
That being said it is impossible to validate an email without a round trip to the owner, but at least we can reject data that is extremely suspect.

I took a look at the regex in pooh17's answer and noticed it allows the local part to be greater than 64 characters if separated by periods (it just checked the bit before the first period is less than 64 characters). You can make use of positive lookahead to improve this, here's my suggestion if you're really wanting a regex for this
^(((?=.{1,64}#)[^<>()[\].,;:\s#"]+(\.[^<>()[\].,;:\s#"]+)*)|((?=.{1,66}#)".+"))#(?=.{1,255}$)(\[(IPv6:)?[\dA-Fa-f:.]+]|(?!.*?\.\.)(([^\s!"#$%&'()*+,./:;<=>?#[\]^_`{|}~]+\.?)+[^\s!"#$%&'()*+,./:;<=>?#[\]^_`{|}~]{2,}))$

Building on #Matas Vaitkevicius' answer: I've fixed up the regex some more in Python, to have it match valid email addresses as defined on this page and this page of wikipedia, using that awesome regex101 website: https://regex101.com/r/uP2oL7/26
^(([^<>()\[\]\.,;:\s#\"]{1,64}(\.[^<>()\[\]\.,;:\s#\"]+)*)|(\".+\"))#\[*(?!.*?\.\.)(([^<>()[\]\.,;\s#\"]+\.?)+[^<>()[\]\.,;\s#\"]{2,})\]?
Hope this helps someone!:)

How do I separate multiple email addresses in cfmail

Do I use a comma or semicolon? I can't seem to find it in the live docs. I also can't seem to find any consistency looking online as some examples use a comma while others use a semicolon. Are both acceptable?

Per https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-m-o/cfmail.html
Message recipient e-mail addresses:
Static address, for example, "support#.com".
Variable that contains an address, for example, "#Form.Email#".
Name of a query column that contains an address, for example,
"#EMail#". An e-mail message is sent
for each returned row.
To specify multiple addresses,
separate the addresses with commas.
(emphasis mine)
I do believe semicolons will work as well.

You can use either of them, and it should be fine. Although for consistency with existing email clients, I'd use a semicolon.
I'm not sure how commas would behave in other CF engines, such as Railo or OpenBD, whereas ; would work on all of them.

Comma separate the email addresses is the answer i found in o'reilly's coldfusion book. its possible semi-colons will work, but commas for sure.
-Don

I think it depends on your mail server. If you're using Exchange, it expects semicolons. Most smtp servers prefer commas. Experiment and see what works for you.