[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Domainkeys and ISPs



Matus UHLAR - fantomas wrote:
>> On Wed, Mar 12, 2008 at 12:29 PM, Andrew McGlashan
>> <andrew.mcglashan@affinityvision.com.au> wrote:
>>>  I haven't read about this widely, but I would presume that it would make
>>>  sense that the originating mail server should add their domain key
>>>  information and any forwarding server should leave it in tact.
> 
> On 12.03.08 14:44, Jim Popovitch wrote:
>> That also won't work with mailinglists where the original email is
>> modified (headers/footers/etc) and resent.  BUT, while DK has it's
>> merits, adding it to a large volume mailinglist can be counter
>> productive due to the overhead in signing each outbound email.
> 
> The list software has to take care about the message - verify signature and
> add own one. Unless it resends the message as attachment, of course :)
> It requires only one verify and one sign process, so I don't find that as
> big problem.

I just had a test with dkimproxy. A very simple test with the mailx
package (eg: Mail from the command line).

When sending a mail from another server to my test server, dkimproxy
found that the originator didn't sign the mail (which is right), and
forwarded the message without adding any signature. If I send a mail
from my test server, it signs the email normally.

The way it works, I think, is that dkimproxy only signs email that it
knows about in it's start file. In my start file, I have (interesting
part only):


DKIM_HOSTNAME=`hostname -f`
DOMAIN=`cat /var/lib/dtc/etc/local_domains | \
tr \\\r\\\n ,,`${DKIM_HOSTNAME}

DKIMPROXY_OUT_ARGS="--keyfile=${DKIMPROXY_OUT_PRIVKEY} \
--selector=postfix --domain=${DOMAIN} --method=simple \
--signature=dkim --signature domainkeys 127.0.0.1:10028 127.0.0.1:10029"
[...SNIP...]
start-stop-daemon --background --make-pidfile --start \
-p ${PIDDKIMPROXY_IN} -u ${DKIMPROXYUSER} \
-g ${DKIMPROXYGROUP} -x ${DKIMPROXY_IN_BIN} -- ${DKIMPROXY_IN_ARGS}

So as you see, dkimproxy needs a list of domains for which it signs
email. If you are receiving a mail from another server, and then
forwards it, of course, it's not in the list, and then it's not signed.
That made sense, so I didn't bother to get in touch with the upstream.

I don't know what's going to happen in the case of mailing lists
though... I use MLMMJ, which I really believe is the best mailing list
manager around (a lot better, modern, and maintained than mailman, at
least). My guess is that it wouldn't sign the mail at all, as the From:
is not the list address, but I would find it quite normal: why would you
sign a mail that is not sent by one of your trusted domains in the first
place, even though it's forwarded by a mailing list? It could be spam
too, and in fact, there's lot's of spam going through mailing lists.
That makes sense to me NOT to sign it.

By the way, whenever possible, I always select "subscriberonlypost"
option in MLMMJ, as this really discards ALL spams. I know it's not
always possible (like for some of the lists in Debian), as you might
want users to still be able to send to the list without subscribing. But
whenever possible, set this restriction.

I hope that helps,

Thomas


Reply to: