[dmarc-discuss] MLM and Header-From rewritting - the SMTPopen-relay analogy

Murray S. Kucherawy superuser at gmail.com
Mon Jun 9 11:34:41 PDT 2014

On Mon, Jun 9, 2014 at 10:49 AM, Larry Finch <finches at portadmiral.org>

> I think that is the reason. Users for the most part are trusting. If an
> email says it comes from their bank they believe it. Most banks have gone
> to great lengths to make it easy to verify that a message really comes from
> the bank, such as including an account balance, or the last N digits of the
> account number. But if the message appears to come from the bank but
> doesn’t have verification data they don’t notice that it doesn’t and click
> on the link anyway. I’m pessimistic that anything can ever be done with the
> invisible parts to prevent phishing scams and spam, because all the message
> has to say it is from the bank and enough users will be fooled by it to
> keep the cyber criminals in business. Some phishing emails even attempt to
> spoof the bank verification by showing the FIRST 4 digits of the account
> number, which, of course, is unique for each issuer. See Brian Krebs’s blog
> (http://krebsonsecurity.com/) for just how big a business cyber crime is.
> It isn’t going to give up its multi-$billion revenue stream easily.
> User education (if that is possible) is the best defense.

I seem to recall a presentation some years ago that discovered over 18% of
users go through their spam folders and fall for phishes found in there, on
the basis that the spam filtering might cause them to miss something
important.  One can easily conclude that user education is an uphill
battle, or at least hasn't worked thus far, and opt for solutions that try
to take the user out of that decision process.  This is why S/MIME, though
quite possibly a workable solution, is routinely disqualified.

It's interesting, but also sad for email, that Kaiser (and perhaps others)
has decided this problem is intractable.  Now, when my doctor sends me a
message, I get an email asking me to go to their web site to retrieve the
message.  It's a bit annoying to have to log in to a web site to read a
single message, but we're guaranteed mutual authentication and message
security that way.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dmarc.org/pipermail/dmarc-discuss/attachments/20140609/48cbb47b/attachment.html>

More information about the dmarc-discuss mailing list