I understand that DKIM can be used to prevent the spoofing of the "From:" header in an email. Email receivers can validate the DKIM-Signature to verify the "From:" header.
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; **d=example.com**;
h=from:to:subject:content-type; **s=smtpapi**;
bh=Qdu07jaeIipfZPkXZqzhD3HXzeo=; b=skdennE1MwDXUGfm/mox/OF8MJjaq
jrE3ETrbeE4PdvokFigU5qTuf2LJ8M9MmxCm4ji6G+CG4u7eKeCdMgAFgEwZCVhp
8UFYUwXkHFqgzKznGremWWHaXU9aIzUtWyFuOziZhqcP3Jn7/V8xyaCEIPP0dz6b
aaaI87oazVBMp8=
From: CEO <ceo#example.com>
For instance, in this email header, the DKIM-Signature says to check "smtpapi._domainkey.example.com" for the public key used to sign the email headers.
But couldn't the attacker simply replace the entire DKIM-Signature content to point to another domain that they control, and re-generate the DKIM-Signature with a set of keys that they own? This would create a valid DKIM-Signature, but would allow email spoofing.
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; **d=attackerDomain.net**;
h=from:to:subject:content-type; **s=attackerKey**;
bh=Qdu07jaeIipfZPkXZqzhD3HXzeo=; b=skdennE1MwDXUGfm/mox/OF8MJjaq
jrE3ETrbeE4PdvokFigU5qTuf2LJ8M9MmxCm4ji6G+CG4u7eKeCdMgAFgEwZCVhp
8UFYUwXkHFqgzKznGremWWHaXU9aIzUtWyFuOziZhqcP3Jn7/V8xyaCEIPP0dz6b
aaaI87oazVBMp8=
From: CEO <ceo#example.com>
Using DKIM, would an email receiver be able to determine that the first email is valid, while the second email is spoofed? How does the email receiver know which DKIM servers are authoritative for the "example.com" domain? (example.com vs attackerDomain.net)
If they created a new key pair and point it to their domain, then they would be authenticating on said domain and not the domain they are trying to spoof.
In order for them to spoof a legitimate domain, they would need to obtain your private key. Therefore, signing out on their mail server with the private key.
However, they will not pass SPF authentication because the server they are sending from are not authorized.
When your legitimate mail server sends out mail, it will sign the mail with a crypto signature using your private key. The receiving e-mail servers does a look up on the public key (remember, its your public key that you publish yourself) and validates it.
SHORT ANSWER:
DKIM makes impersonation DIFFICULT, not IMPOSSIBLE:
All a DKIM validated email proves is that it came from the domain whose key signed it. It might have come from a legitimate member of the organization, or it might be from a hacker who has gained access to their DKIM configured mail server either as an open-relay or through a compromised user's account that could put mail through the server.
But an email FAILING DKIM validation on the recipient's mail server DOES necessarily prove forgery and/or tampering in transit. A subtle but very important nuance.
So the only thing a DKIM signed email can prove in absolute terms is in the case of FAILED test: the email is either spoofed and/or has been modified in transit. An email PASSING DKIM validation only proves the mail was signed by the domain's key.
And in the case of an unauthorized user- somebody without a set of credentials issued by the organization to use their mail server- or an open-relay, then DKIM validation can actually serve to confer credibility on a bad actor leading staff to let their guard down when considering its' content.
LONGER Answer:
I received a DKIM signed email notifying me:
The password for your email account (victim#example.com) expires today 10/11/2022 12:01:50 p.m..
Keep and continue with the same password using the below portal.
I opened "view Source" and the link to the button was revealed to be:
https://jccm.com.ve/wap/MailUpdateFresh/index.html#victim#example.com
I found such a claim incredulous as I configured and administrate my own mail server. I have no relationship with any companies in Venezuela in respect to the provision of my mail services.
This clearly was a phishing email.
How did the Phishing email pass DKIM Validation?
So I checked the headers and found the email had successfully passed DKIM validation:
Received-SPF: pass (ee-smarts.top: 106.75.143.14 is authorized to use
'sales#ee-smarts.top' in 'mfrom' identity (mechanism 'a' matched))
receiver=mail.example.com; identity=mailfrom; envelope-
from="sales#ee-smarts.top"; helo=ee-smarts.top; client-ip=106.75.143.14
Authentication-Results: mail.example.com;
dkim=pass (1024-bit key; unprotected) header.d=ee-smarts.top
header.i=sales#ee-smarts.top header.a=rsa-sha1 header.s=default header.b=EO/D+N5H
Received: from ee-smarts.top (ee-smarts.top [106.75.143.14])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.example.com (Postfix) with ESMTPS id BD4245DAF4
for <victim#example.com>; Tue, 11 Oct 2022 13:02:44 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=default; d=ee-smarts.top;
Using the value of s=default in the header I then checked the TXT record for the key:
host -t txt default._domainkey.ee-smarts.top
default._domainkey.ee-smarts.top descriptive text "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCteqwk5m985UgrkYNFy0U6I6k+
QYGTilepE1Mrit5+LXAMFVfdArvbK99AljxpbSOJEOYvkQmAqgtCBgD0tlSmGjiFCQ
A7ylPzp9Owsq/OCPjpAMWA/eHwZua8FKFwPcPvRpww34z9lNr0+XJOb5+6B16tV+BK
La5y8fUgpCLKGQIDAQAB"
As far as I could see, the sending mail server WAS configured for DKIM and thus my own mail server rightly passed the validation.
So What happened?
Only two things were possible:
Either somebody was foolish enough to DKIM-sign phishing emails from their own domain OR
The phisihing email was passed through a DKIM-configured OPEN-RELAY mail server
Further investigation revealed the later was the case:
The following are attempts from publically listed open relays on
ordb.org, spamhaus.org and spamcop.net. If you're here, don't contact us
to get off. We do not determine who is in the ORDB. (These are the
connect attempts we've denied for the previous day)
What was the trick?
The miscreants weren't trying to get me to respond to the message itself, but merely trick me into clicking on a link in the email which now had DKIM-conferred credibility to trick me into compromising my email account credentials. Notice they didn't want me to CHANGE my credentials: the Phishers' defaults were "KEEP SAME PASSWORD"
Conclusion
In this case, DKIM served to confer a high level of credibility to phishers attempting to gain my email credentials. So DKIM works, but only if the DKIM configured mail server is not an open-relay. Thus, DKIM cannot 100% guarantee that impersonation is not possible in the case of an Open-Relay. This is a serious achilles' heal with DKIM from my own observations.
Related
I setup a clean iRedMail installation on a new server.
I followed the instructions here:
https://docs.iredmail.org/install.iredmail.on.debian.ubuntu.html
and then setup the dns records like so:
https://docs.iredmail.org/setup.dns.html
I also added a certbot certificate: https://docs.iredmail.org/letsencrypt.html
I can now receive email from all other email providers and can send email to other users of my domain. But I cannot send email to other email providers, it doesn't even end up in the spam folder.
After some research i found out that my emails are missing a dkim signature which is the most likely reason they aren't picked up by other servers.
I did the amavisd-new testkeys test and passed, although I'm pretty sure it doesn't work, since it also works if I don't setup any DNS records.
So my questions are:
shouldn't my emails be DKIM signed for some reason?
which service is responsible for adding DKIM headers to emails?
Where can I find out why it doesn't sign my mails?
Turns out Amazon blocks outgoing traffic on port 15 by default. Took me a while to figure out. There was no problem with DKIM.
I'm trying to send an SMTP Email to SendGrid using Telnet and getting "535 Authentication failed: The provided authorization grant is invalid, expired, or revoked" as a response when I enter my base64 encoded API Key.
I have authenticated my domain.
I have a Full Access SendGrid API Key (and converted it to base64).
I have created and verified a sender (but, it has a mere ...#gmail.com address).
I am following the steps at https://docs.sendgrid.com/for-developers/sending-email/getting-started-smtp.
I have tried port 25 and port 587, but I can't get beyond step 4: Enter your Base64 converted API Key.
What could be causing this error?
Do I need to create a sender with a business email address?
Do I need a paid SendGrid plan?
I have already set up PHPMailer and it already worked with one domain,
using a gmail account for the SMTP service.
When I wanted to use PHPMailer, likewise, with a different
Gmail account (for a different virtual host),
it would still send it from the same Gmail acccount
because that's what is identified as "the email address" of the server
(of the server on which severe virtual hosts run)
my question is, what do you need to have in order to be able to be able to use
another Gmail account?
another IP address? or another server? or?
and what will be the ultimate limitations in terms of the FROM ADDRESS
if you only have one IP address and one server?
thank you
Gmail does not mind you using multiple accounts from the same IP, so long as you authenticate correctly for each. That is, there is no fixed relationship between the server you're sending from and the gmail account you use.
The one thing that will be the same across accounts is the EHLO hostname (set via PHPMailer's Helo property, if it can't be derived automatically), because you really want that to resolve backwards as well as forwards in DNS, and you can't do that with multiple names at once - but that has no effect on authentication.
There's no need for the actual hostname of the server to be related to the domain you're sending from, so you can safely say:
$mail->From = 'user#vhost1.example.com';
$mail->Username = 'user#gmail.com';
and then, in another vhost:
$mail->From = 'user#vhost2.example.com';
$mail->Username = 'user2#gmail.com';
If you watch the SMTP conversation (SMTPDebug = 2), both will have the same EHLO name (which might be a generic host.example.com), but then use different authentication and MAIL FROM addresses (the SMTP source address, which may be different from what's in the message's from header if you make use of the Sender property, but either way it will be turned into a return-path header by the receiver) for sending the messages.
The problem I have is that I need to test if user verification is working. We generate a verification token, and an email is sent to the user. Whenever the user clicks on it, it checks if the verification token has expired. I've tried mocking this, but it just won't work. We have an endpoint to verify a user, but we still need the verification token, which is not available on any endpoint.
I think this article may help you: https://www.testingexcellence.com/automated-api-testing-emails-karate/
To summarize:
use the API at http://qamail.ala.se/ to create a test mailbox
initiate the flow that sends the e-mail
use the API to "read" the e-mail and grab the token
EDIT: looks like the link is dead. but you should be able to find similar offerings on the internet. since the source-code seems to be available, it may make sense for you to host this e-mail server somewhere so that it can receive e-mail from whichever system is the sender
I am using Exchange Web Services (EWS) to read emails and their attachments. I was successful until I started receiving some emails that were digitally signed. I found this link EWS: Retrieving attachments from signed emails where the solution starts off by saying "... Assuming your security context has access to the key. " which is exactly where it seems I have problem. How can I make sure my security context has access to the key? How do I achieve that? The code in the above link gives me an error: ASN1 bad tag value met
Are the messages signed or Encrypted (or both) ? To decrypt an encrypted message you would need to have the Private Key (eg for SMIME these should have been exchanged) the EnvelopedCms will search current user (security context) and computer certificate store for this certificate information. However in Exchange in addition to being stored locally the certificate that could be used to decrypt the message could be stored as an attachment on a Personal Contact or in Active Directory http://blogs.technet.com/b/exchange/archive/2008/04/23/3405402.aspx.