On 2013-07-24 18:10, Alessandro Vesely wrote:
> On Wed 24/Jul/2013 13:39:37 +0200 Anders wrote:
>> I'll comment in-line.
> Yup :-)
>
>> I am using zdkimfilter-1.2 , provided by gentoo ebuild/portage. Compiler
>> is gcc 4.7.3
> I haven't been able to find that version --see below.
>
>>> I think that's because you set RELAYCLIENT based on the IP address,
>>> and have no authsender in the control file (a control record starting
>>> with 'i').  The signing domain is derived from the user id, if it has
>>> a '@'.  Courier can work both ways, zdkimfilter should do so as well.
>> I am using courier with virtual users mapped through mysql. The full
>> email address is the user name.
> So do I.
>
>> What is a control record, and where/how do I find how they are created
>> and looks like?
> Control files only exist in the mail queue.  They are named Cnnnnnnn
> and correspond to the Dnnnnnnn mail file with the same number.  They
> are loosely documented in http://www.courier-mta.org/queue.html
>
>>>> I run "dkimsign test.mail" and get the following output:
>>>> ======================
>>>> WARN: zfilter: zdkimfilter[27853]:Mismatched library versions:
>>>> compile=0X2020200 link=0X2080400
>>> (That warning is due to a mismatch between libopendkim-dev and the
>>> actual libopendkim library.  It might cause hiccups when verifying
>>> signatures --not the current issue.
>> OK,  does this happen at compile time, or is it something predefined by
>> zdkimfiler code? Looks like it was compiled against opendkim 2.2.2, but
>> I actually have only opendkim 2.8.4 installed (Gentoo
>> mail-filter/opendkim-2.8.4).
> Yes, it is a compile time conditional.
>
> I checked
> http://packages.gentoo.org/package/mail-filter/opendkim
> http://packages.gentoo.org/package/mail-filter/zdkimfilter
> I found opendkim-2.8.4 (that was released on the 16th this month), but
> zdkimfilter-1.1 not 1.2
>
> The opendkim-2.2.2 version they used to build zdkimfilter seems to be
> lost.

I realise I have a local overlay with zdkimfilter-1.2. I will revert to 1.1.

Should I downgrade opendkim-2.2.2?
>
>> ========================
>> # ls -l /usr/lib64/libopendkim*
>> lrwxrwxrwx 1 root root     20 Jul 24 12:51 /usr/lib64/libopendkim.so ->
>> libopendkim.so.9.0.1
>> lrwxrwxrwx 1 root root     20 Jul 24 12:51 /usr/lib64/libopendkim.so.9
>> -> libopendkim.so.9.0.1
>> -rwxr-xr-x 1 root root 136200 Jul 24 12:50 /usr/lib64/libopendkim.so.9.0.1
>> ========================
>>
>> I did notice a segmentation fault with courier/zdkimfilter once I have
>> started with filterctl. It happens on every received email:
>> ========================
>> Jul 24 13:09:14 e350 courieresmtpd: started,ip=[::ffff:216.34.181.88]
>> Jul 24 13:09:17 e350 courierfilter: zdkimfilter[13997]: started child
>> Jul 24 13:09:17 e350 courieresmtpd:
>> error,relay=::ffff:216.34.181.88,from=<courier-users-boun...@lists.sourceforge.net>:
>> 432 Mail filters temporarily unavailable.
>> Jul 24 13:09:17 e350 submit: Bad file descriptor
>> Jul 24 13:09:17 e350 submit: Connection closed when processing:
>> Jul 24 13:09:17 e350 courierfilter: zdkimfilter[13997]:reading 2 names
>> completed by first call
>> Jul 24 13:09:17 e350 courierfilter:
>> zdkimfilter[13997]:id=0000000000C804F7.0000000051EFB5DC.000036A7:
>> verifying dkim_eoh: No signature (stat=2)
>> ========================
>>
>> ...and kernel log
>> ========================
>> [2329247.997445] zdkimfilter[12231]: segfault at e ip 00007f41ffb36411
>> sp 00007fff9d08ce00 error 4 in libopendkim.so.9.0.1[7f41ffb25000+20000]
>> [2329937.290754] zdkimfilter[13997]: segfault at e ip 00007f41ffb36411
>> sp 00007fff9d08ce00 error 4 in libopendkim.so.9.0.1[7f41ffb25000+20000]
>> ========================
> We should file a bug report.  I would have done it myself if the
> version matched.  There is a function, dkim_policy(), which takes
> three parameters in opendkim 2.2.2, but takes four in version 2.8.4.
> Depending on the optimizations used at compile time, it might cause
> such behavior.  In fact, zdkimfilter calls that function when it
> verifies signatures in received messages.
>
>>>> I run "dkimsign --domain lechevalier.se test.mail"
>>> Yes, dkimsign needs the domain to create a control file similar to
>>> those supplied by Courier.
>> OK, so all seems OK so far then?
> Yeah, I use dkimsign that way to sign messages going out through
> sqwebmail.  Possibly, you could prepend it to the mail pipe, until
> this issue is cleared.
>
>>> You should have got at least a "not signing for /user id/: no
>>> /something/" message if it had entered signing mode.  That's why I
>>> think you don't authenticate on sending.  Please confirm that.  I'll
>>> add a message for that case anyway.
>> No all users must authenticate to be able to send emails (relaying
>> denied otherwise).  It could be that my courier config is completely
>> wrong, should I post it here? In that case, which of the config files
>> are interresting for you?
>>
>>
>> Output from sending a test email from and...@lechevalier.se to
>> crimsoncott...@gmail.com. At least "from=" is clearly defined in the log
>> file.
> There is a key_choice_header parameter that can be tweaked in order to
> derive the signing domain.  Currently, it can be derived from a header
> field, from the authenticated user-id, or from the default domain.
> Hence it misses the possibility to derive it from the envelope sender,
> which is what you get in the logged from= quoted below.  But there is
> another problem:  If the sender is not authenticated, the current
> version doesn't even enter signing mode.
> We'd need to change the code slightly to obtain such feature.
Seems like a possible future feature, but I do want authentication, so 
the problem must be my courier setup.


>> ====================
>> Jul 24 13:33:33 e350 courierd:
>> newmsg,id=0000000000C804F7.0000000051EFBB8D.00004626: dns;
>> [IPv6:2001:16d8:ff02:0:3d19:ef23:9df5:18fe]
>> ([2001:16d8:ff02:0:3d19:ef23:9df5:18fe])
>> Jul 24 13:33:33 e350 courierd:
>> started,id=0000000000C804F7.0000000051EFBB8D.00004626,from=<and...@lechevalier.se>,module=esmtp,host=gmail.com,addr=<crimsoncott...@gmail.com>
>> Jul 24 13:33:33 e350 courierd: Waiting.  shutdown time=none, wakeup
>> time=none, queuedelivering=1, inprogress=1
>> Jul 24 13:33:34 e350 courieresmtp:
>> id=0000000000C804F7.0000000051EFBB8D.00004626,from=<and...@lechevalier.se>,addr=<crimsoncott...@gmail.com>:
>> 250 2.0.0 OK 1374665609 g5si1547113laa.79 - gsmtp
>> Jul 24 13:33:34 e350 courieresmtp:
>> id=0000000000C804F7.0000000051EFBB8D.00004626,from=<and...@lechevalier.se>,addr=<crimsoncott...@gmail.com>,size=630,success:
>> delivered: gmail-smtp-in.l.google.com [173.194.71.26]
>> Jul 24 13:33:34 e350 courieresmtp:
>> id=0000000000C804F7.0000000051EFBB8D.00004626,from=<and...@lechevalier.se>,addr=<crimsoncott...@gmail.com>,size=630,status:
>> success
>> Jul 24 13:33:34 e350 courierd:
>> completed,id=0000000000C804F7.0000000051EFBB8D.00004626
>> Jul 24 13:33:34 e350 courierd: Waiting.  shutdown time=Wed Jul 24
>> 13:45:45 2013, wakeup time=Wed Jul 24 13:45:45 2013, queuedelivering=0,
>> inprogress=0
>> ====================
>>
>>
>> This is doing a simple "echo test | mail -s testmail
>> crimsoncott...@gmail.com" as root user:
>> ====================
>> Jul 24 13:37:01 e350 courierd:
>> newmsg,id=0000000000C804F7.0000000051EFBC5D.00004851: dns; localhost
>> (localhost [127.0.0.1])
> If you had authenticated, there would have been an additional
> "auth=userid@domain".
>
> The best practice for sending messages is to use submission port 587
> and one of the available login features, me thinks.
>
> In order to cope with RELAYCLIENT assigned based on IP address, there
> are two easy possibilities that I can see:
>
> 1) Introduce a default_user, but that might be unsuitable if
>     different IP addresses correspond to different users.
>
> 2) Deploy the identd lookup done by Courier (unless -noidentlookup is
>     specified in TCPDOPTS), but that would impact users not having an
>     identd server.
>
> In either case, you'd then need to compile the modified program
> yourself.  What you think?
>
>
>
>
I must say I am at loss about the the auth=userid@domain. Never seen it 
in my logs... I do use port 587 with TLS and authentication with 
username/password to submit email. Perhaps here is where my problem is 
and I need to correct.... sigh =( I do not want relayclient based on IP, 
though that is needed for some local scripting stuff, but not my normal 
users since we should do auth...

I added DEBUG_LOGIN=1 to authdaemondrc and I see authentication when 
logging in with imap, but nothing when submitting on smtp...

Not sure where to look now. any ideas? Thanks!

~A



------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to