On 7/12/23 9:28 AM, Jaroslaw Rafa via mailop wrote:
Despite I said that SPF/DKIM/DMARC adds little to security, I would
disagree with what you write here.
The problem is for recipients, not for senders.
I'd argue that almost all SMTP shortcomings are on the receiving end,
not the sending end.
Assume someone receives a forged mail claiming to be from a delivery
company (like DHL or similar) saying "Your package cannot be
delivered, because additional delivery charge of 1$ is required,
please go here to pay: <and a link to a fake payment gateway>".
Detecting (some large subset of) spoofed senders is the primary use I
see for SPF.
The primary use case I see is spoofed $ADMINISTRATOR from $YOUR_DOMAIN
saying that your password is expiring and needs to be reset or that you
have a quarantined message please check it.
Even if one in 1000 people who receive it logs in to the fake
payment gateway - and in turn will have their online banking
credentials intercepted and their money stolen - it is a HUGE damage
if they send this phish to millions of people.
Agreed.
The same type of attack can be performed by impersonating basically
any company that sells something online, because the key point here
is to direct recipients to the fake payment gateway, which allows the
attacker to steal their money ("their" == recipients, not
impersonated company).
That's one of the key attacks. Another is to harvest email credentials
to be used for other campaigns.
Theoretically SPF/DKIM/DMARC should protect against it. But this type
of messages is also very well recognized and filtered by
antispam/anti-malware software.
I see many examples of it where anti-spam / anti-virus / anti-malware
don't detect it.
Almost all of those examples could easily be detected with SPF.
It's also enough that the attacker uses own domain that is similar to
the impersonated one (for example uses dhl-courier.com or
dhl-poland.com instead of dhl.com; both don't exist as of this
writing) to pass all SPF/DKIM/DMARC tests (while the
antispam/anti-malware software should still properly detect and
filter the message).
I consider that to be a testament to how successful SPF can be such that
it moved the problem from impersonation attack to a look-alike / homonym
attack. As in we caused the spammers to change their tactics because
what they were doing no longer works.
Also, as I already said, this type of attack is usually carried out
using SMS messages to mobile phones, not email (at least huge
majority of phishing campaigns of this type that were reported by
security-related websites in my country were carried out using SMS).
I don't remember any serious phishing incident in recent years that
was related to email.
As an email administrator I can't do anything about SMS attacks. But I
can do something about email attacks.
Maybe this is because of more widespread use of SPF/DKIM/DMARC, but I
rather suppose this is because much more potential victims can be
reached via phone than via e-mail, and because it is much harder to
verify on a phone what website you are logging to. The phishing
message uses a link shortener (which seems understandable because of
the limited length of a text message), people just click on that link
and land on a website that looks just like the real one they are used
to.
I've had people be annoyed with me that their password manager didn't
offer to fill their password on the look-alike website only to later
wish they had not copied and pasted their password after learning that
they had just compromised themself.
Fuses blowing and circuit breakers tripping can be annoying. But they
are doing so for a reason. Things are trying to keep us safe. --
Don't put a penny in the fuse box and then wonder why you have an
electrical fire.
I also think that in the realm of filtering methodologies spam / virus
filtering takes more computing than DMARC filtering, which takes more
computing than DKIM, which takes more computing than SPF, which takes
more computing than basic TCP connection filtering. As such I try to do
filtering using the fewest computational resources and thus start with
the simpler things and work up in computational cost; TCP connection
filtering -> SPF filtering -> DKIM filtering -> DMARC filtering -> spam
/ AV filtering. Can SpamAssassin detect something that fails SPF, quite
likely. Do I need the 800 lb gorilla that is SpamAssassin when I can
use the 80 lb monkey that is SPF? Nope. I can use the 80 lb monkey
perfectly fine.
As you say, the problem is for recipients. So, why force the
recipient's hand to use an 800 lb gorilla when they could use the 80 lb
monkey if you simply provide them data to give the 80 lb monkey in the
form of publish SPF information.
IMHO, some -- but not all -- that choose not to publish any information
to make the recipient's lives any easier are somewhat choosing to say "I
don't care, I'm not going to lift a finger, and you must do all the
work, even if it's ten times the work compared to if I had given you the
smallest amount of data." -- I try to be a better net'itizen than
that. A few people / organizations have very specific reasons for not
publishing information.
Grant. . . .
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
