#37 Perhaps a bug when Sender: is overwritten

v0.6.5
closed
5
2007-05-04
2007-04-23
Ache
No

Please consider following sequence. I send mail to the list with

From: name1@their.domain.com
Sender: name2@my.domain.com

It is correctly signed at my.domain.com using Sender:,
but afterwards their mailing list overwrites Sender: to looks like:

Sender: list-owner@their.domain.com

I got "bad signature data" when mail is returned, which is right, but strange and confusing syslog message and header field from dkim-filter:

Authentication-Results: my.domain.com
header.Sender=list-owner@my.domain.com; dkim=fail
^^^^^^^^^^^^^^
(verification failed)

Why "header.Sender" there is list-owner@my.domain.com instead of list-owner@their.domain.com? What happens, if I'll have, by chance list-owner as my local user, i.e. valid list-owner@my.domain.com?

BTW, just a question. Is there any way to get mail to the list signed using some other header field besides From: and Sender: ?

Discussion

    • assigned_to: nobody --> sm-msk
     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    I've reproduced this now; investigating.

     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    dkim-filter is just reporting the results from dkim_getidentity(), so I need to verify the logic being applied in there to determine the identity of the sender.

     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    Looks like it's preferring the domain from the d= in the signature when generating the value returned by dkim_getidentity().

    There are legitimate reasons to want that, so I need to figure out how I want to adjust the API to be able to get either case.

     
  • Ache
    Ache
    2007-05-02

    Logged In: YES
    user_id=295536
    Originator: YES

    Basically it needs to detect somehow that Sender (or From) becomes overwriten to produce something like this
    header.Sender=Changed!
    but the only way to detect is to store signer field somewhere in the DKIM tag and put into signature. I am not sure is at allowed by specs. If yes, there is another way possible: just put
    header.Sender=saved_in_the_signature_sender

     
  • Logged In: YES
    user_id=1048957
    Originator: NO

    Unfortunately your suggestions wouldn't fit within the specification of Authentication-Results:.

    The problem was the logic in dkim_getidentity() which munged the returned value by mixing up the sender's domain name and the signer's domain name. Fixed in v0.7.0.

     
    • status: open --> closed