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

From: Murray S. Kucherawy <>
Date: Fri, 10 Sep 2010 11:24:33 -0700

> -----Original Message-----
> From: [mailto:opendkim-users-
>] On Behalf Of Miha Vrhovnik
> Sent: Friday, September 10, 2010 9:38 AM
> To:
> Subject: How does opendkim determine on whose behalf to sign message?
> [...]
> 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.

This is the main reason why both the From: domain and the client IP are checked before the decision to sign is made. Someone that is not coming from an authorized source won't be able to get mail signed even if the domain is one for which you would normally sign.

As someone else mentioned you can use the Lua script hooks to determine whether or not the client has authenticated, for example. For that matter you can check any MTA-provided macro value, and thus co-ordinate between the two some way of indicating whether or not this is an authorized client.

You can also tell the filter to make the decision based on a different header field or a macro if that's what you'd prefer. In the former case you want the SenderHeaders setting; in the latter, compile with "--enable-sender_macro" and use the SenderMacro setting. If you want to base it on the envelope sender, I believe that's available in an MTA macro.
Received on Fri Sep 10 2010 - 18:24:41 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:48 PST