I sent an email via Apple’s “Hide My Email” service [1].
Unhandled Promise Rejection:
TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)
dist.min.js:3:32767
This error occurred after the interface began displaying the following information:
Here are the message headers and message body:
DKIM-Signature: d=icloud.com s=1a1hai
It’s been over a year since the website was featured on Hacker News (January 10, 2022), so I suspect that the JavaScript code may have become outdated and non-functional. It’s possible that it never supported Safari browsers in the first place, or perhaps it’s a combination of both issues. Nevertheless, I’ve learned a lot from the initial [2] and second [3] parts of the DMARC test, which gives me some insight into what might be happening in the subsequent steps.
I also get the same error (in Chrome) when testing a forged email:
telnet learndmarc.com 25
Trying 87.239.13.42...
Connected to learndmarc.com.
Escape character is '^]'.
220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000
HELO there
250 allspark.uriports.com Hello <my host> [<ip address>]
MAIL From: me@example.com
250 OK
RCPT To: ld-49101f55f6@learndmarc.com
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
.
250 OK id=1qn4QF-00CUhd-5j
It's funny because while I was typing this, it's like "you don't have to write a love letter". Maybe not, but you do have to repeat the From: and To: header in the data segment, I guess.
I remain amused at how much email I've sent over the years with "HELO there" instead of my hostname in there. I also wonder what % of internet traffic is "Enter message, ending with . on a line by itself".
You sent an email without a "from" field and it broke. Programmer didn't think to test for bad users doing bad things. Nothing special here, no big conspiracy.
If this is true and Apple's service does leave out a "from" header (it may just as well be a parse error somewhere on the website's side) that would definitely be on the mail forwarding service, not on this particular website.
RFC 5322 and RFC 2822 specify that at least and at most one From: header must be present. Mail services that don't add at least some kind of fake From header aren't spec compliant and should probably expect error and delivery problems. RFC 2822 is over 20 years old now.
In theory Apple's service could only be RFC 822 compliant, but this does pose a big interoperability problem for its customers.
As DMARC relies on the RFC5322.From address, omitting it will lead to errors. To avoid these errors, emails lacking this address are currently being ignored.
Comments
I sent an email via Apple’s “Hide My Email” service [1].
This error occurred after the interface began displaying the following information:
It’s been over a year since the website was featured on Hacker News (January 10, 2022), so I suspect that the JavaScript code may have become outdated and non-functional. It’s possible that it never supported Safari browsers in the first place, or perhaps it’s a combination of both issues. Nevertheless, I’ve learned a lot from the initial [2] and second [3] parts of the DMARC test, which gives me some insight into what might be happening in the subsequent steps.
[1] https://support.apple.com/en-us/HT210425
[2] dig +noall +answer -t TXT <EMAIL_DOMAIN> | grep -i SPF
[3] dig +noall +answer -t A <HOSTNAME>
I also get the same error (in Chrome) when testing a forged email:
It's funny because while I was typing this, it's like "you don't have to write a love letter". Maybe not, but you do have to repeat the From: and To: header in the data segment, I guess.I remain amused at how much email I've sent over the years with "HELO there" instead of my hostname in there. I also wonder what % of internet traffic is "Enter message, ending with . on a line by itself".
You sent an email without a "from" field and it broke. Programmer didn't think to test for bad users doing bad things. Nothing special here, no big conspiracy.
It's not a "bad user doing bad things," it's a widely-used email forwarding service.
If this is true and Apple's service does leave out a "from" header (it may just as well be a parse error somewhere on the website's side) that would definitely be on the mail forwarding service, not on this particular website.
RFC 5322 and RFC 2822 specify that at least and at most one From: header must be present. Mail services that don't add at least some kind of fake From header aren't spec compliant and should probably expect error and delivery problems. RFC 2822 is over 20 years old now.
In theory Apple's service could only be RFC 822 compliant, but this does pose a big interoperability problem for its customers.
As DMARC relies on the RFC5322.From address, omitting it will lead to errors. To avoid these errors, emails lacking this address are currently being ignored.