Re: How does opendkim determine on whose behalf to sign message?

On Fri, Sep 10, 2010 at 06:38:17PM +0200, Miha Vrhovnik wrote:
> Hi
>
> First some background info.
> I've set opendkim to sign messages, the keys and domain list are
> fetched from db, and that part seems to be working just fine. Opendkim
> is set as milter in postfix configuration.
>
> The problem I'm having is the way opendkim is choosing on how to sign a
> message. It seems that it's taking the from field which I found strange
> as this can easily be faked. and it means that there is a giant hole
> that can be exploited e.g The message content can be different from the
> actual message sender (MAIL FROM command issued to the )
>
> Shouldn't the decision on for which domain to sign message be taken
> from the MAIL FROM, or at least mail from should equal the From header
> in message itself.
>
> I know that sender (MAIL FROM) can also be faked, but the way I've set
> up postfix is that the sender must be a valid alias for a login name,
> or relaying is denied, so there is no issue with fakes.

The reason for selecting the From: header vs. the MAIL FROM is one of
client visibility. Many clients display only the From: header, the
MAIL FROM is only visible as Sender: or Return-Path: or some such.

As far as forgability goes, that's a non-issue. opendkim may be using
that as the domain to sign as, but it's not using that for making
the sign/don't sign decision. For that, it uses one of the following:

InternalHosts
        Compare the source IP against this dataset. Only sign the
        message iff you trust the source, and the From: header is one
        you will sign for (SigningTable or Domain).

MacroList
        I typically use this to ask the MTA "Did the signer authenticate
        with the MTA?" via the auth_authen macro. If they did, the
        assumption is that they are a valid local user and therefore
        this message should be signed assuming all other criteria are
        valid.

MTAList
        Similar logic to the the way I use MacroList, I specify an
        MTA Daemon name that requires Authentication for its use
        e.g. the MSA port. If the connection is coming in via that
        daemon, they authenticated so I know they are a legitimate
        local user. Sign it if possible.

None of these deal with the intentionally forged message from a local
user or source that wants to claim to be someone else. However, one
assumes that your logs are sufficient that you can trace those changes.
"Oh look... mail authed as joe_at_example.com, but was signed as
ceo_at_example.com. Maybe this is worth an investigation"

Honestly, I've not needed to look for that, but I think the data is
available. You'd only really need to track it as part of an ABUSE
investigation, I'd think. Unless mgmt wanted a report on it <shudder>

It really all comes down to trust. If you don't trust your users
to do the right thing, you might need to add a rule or two somewhere
that enforces something where "you authenticated make sure that jives
with your From: header"

-- 
 /  \__  | Richard Rognlie / Sendmail Ninja / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/~rrognlie    <rrognlie at gamerz.net>
 /  \__/ | Creator of pbmserv_at_gamerz.net
 \__/    |                Helping reduce world productivity since 1994