[BlueOnyx:21688] Re: mailserver; possible security issue?

[Michael Stauber]

Hi Dirk,

> MAIL FROM:mstxxx at solxxx.net
> 250 2.1.0 mstxxx at solxxx.net... Sender ok
> RCPT TO: mstxxx at solxxx.net
> 451 4.7.1 Greylisting in action, please come back later
> RCPT TO: mstxxx at solxxx.net
> 250 2.1.5 mstxxx at solxxx.net... Recipient ok

I wonder who you sent that email to. :p

Let's see what happened on the receiving end:

The mailserver accepted the email for mstauber at solarspeed.net, but the
email didn't make it to the mbox of the associated user as the AV-SPAM
gave it a SPAM rating of 6.3 points and the account deletes emails with
a score of > 5.0 and rejects emails with a score of 10.00 at the MTA level.

Your email received this score:

Content analysis details:   (6.3 points, 5.0 required)

 pts rule name              description
---- -------------- --------------------------------------------------
 0.0 SPF_HELO_FAIL          SPF: HELO does not match SPF record (fail)
[SPF failed: Please see
http://www.openspf.net/Why?s=helo;id=blackpoint.de;ip=213.198.78.3;r=sol.smd.net]
 1.2 MISSING_HEADERS        Missing To: header
 0.1 MISSING_MID            Missing Message-Id: header
 1.8 MISSING_SUBJECT        Missing Subject: header
 1.0 MISSING_FROM           Missing From: header
 1.4 MISSING_DATE           Missing Date: header
 0.8 BODY_URI_ONLY          Message body is only a URI in one line of
                            text or for an image

However: I do have an email archive set up and that account got a copy
of the email. Which is where the above SpamAssassin report is from.

Even if you had passed Subject, Header or Date via Telnet, the email
would still have been flagged, as it failed the SPF test.

I agree with others that this "works as designed" as far as the MTA is
concerned and that it is not only Sendmail that behaves this way. It's
simply how MTA's are designed to work.

Which makes it entirely a policy and/or common sense issue. The same
fraud could have happened if someone had used a third party mailserver
and simply forged the "FROM:" field to show the address of the CEO.

The question should rather be why the recipient blindly executed a wire
transfer based on an email without any further verification.

Technically there are ways how this could have been prevented: SPF can
be helpful (as shown in this example). Signing and/or encrypting emails
(at least important ones!) could have been immensely important. I also
know people who put a certain pre-agreed phrases in emails they can't
sign or encrypt to give the recipient an idea of the authenticity.

However, the best procedure still is a corporate policy that demands
additional channels and/or methods of authorization for business
transactions that are not entirely based on a protocol with known
security limitations such as email. After all: SMTP is an inherently
flawed protocol.

Can Sendmail be hardened to prevent these kind of things? Yes and no.
Yes, but in ways that make it less practical for roaming clients and you
would need a separate MTA for users *sending* emails than the MTA that
generally receives the emails. Even then the receiving MTA could still
be "fingered" to create forgeries, which would make it again a corporate
policy issue. So ... this isn't really practical and would make email
even more cumbersome as it already is.

I *am* of course open to suggestions. Maybe I overlooked something, but
like said: As is this worked exactly as intended as far as MTA's are
concerned.

-- 
With best regards

Michael Stauber