From: Michael W. <hu...@us...> - 2006-08-27 23:17:47
|
Trying to build the latest version on a Fedora Core 2 server to replace the v0.3.1 version i am currently running and i keep getting the following build error: cc -O2 -I. -I../../include -I../libdkim/ -DNO_SMFI_INSHEADER -D_FFR_ANTICIPATE_SENDMAIL_MUNGE -D_FFR_FLUSH_HEADERS -D_FFR_LOG_SSL_ERRORS -D_FFR_MULTIPLE_KEYS -D_FFR_REPORTINFO -D_FFR_REQUIRED_HEADERS -D_FFR_SELECT_CANONICALIZATION -D_FFR_SELECT_SIGN_HEADERS -D_FFR_SET_DNS_CALLBACK -D_FFR_SET_REPLY -D_FFR_VERIFY_DOMAINKEYS -D_REENTRANT -DXP_MT -c -o dkim-filter.o dkim-filter.c dkim-filter.c: In function `main': dkim-filter.c:4538: error: `cf' undeclared (first use in this function) dkim-filter.c:4538: error: (Each undeclared identifier is reported only once dkim-filter.c:4538: error: for each function it appears in.) make[1]: *** [dkim-filter.o] Error 1 make[1]: Leaving directory `/root/temp/new/dkim-milter-0.5.1 /obj.Linux.2.6.10-2.3.legacy_FC2smp.i686/dkim-filter' make: *** [all] Error 2 Any ideas on how to proceed? Thanks in advance Michael Weiner |
From: Ben L. <BL...@ch...> - 2006-08-28 01:10:20
|
Until someone smarter answers, you should be able to correct that build problem by re-commenting out (^dnl) the line enabling -D_FFR_SELECT_SIGN_HEADERS in dkim-filter/Makefile.m4 and rebuild (make clean; rm -rf obj.*; make). I can reproduce this on Fedora 3 with dkim-milter 0.5.1 using gcc 3.4.4, GNU make 3.80, glibc 2.36 by simply unpacking the 0.5.1 source, enabling -D_FFR_SELECT_SIGN_HEADERS in dkim-filter/Makefile.m4 and attempting a build. > Trying to build the latest version on a Fedora Core 2 server to > replace the > v0.3.1 version i am currently running and i keep getting the > following build > error: > > cc -O2 -I. -I../../include -I../libdkim/ -DNO_SMFI_INSHEADER > -D_FFR_ANTICIPATE_SENDMAIL_MUNGE -D_FFR_FLUSH_HEADERS > -D_FFR_LOG_SSL_ERRORS -D_FFR_MULTIPLE_KEYS -D_FFR_REPORTINFO > -D_FFR_REQUIRED_HEADERS -D_FFR_SELECT_CANONICALIZATION > -D_FFR_SELECT_SIGN_HEADERS -D_FFR_SET_DNS_CALLBACK > -D_FFR_SET_REPLY > -D_FFR_VERIFY_DOMAINKEYS -D_REENTRANT -DXP_MT -c -o > dkim-filter.o > dkim-filter.c > dkim-filter.c: In function `main': > dkim-filter.c:4538: error: `cf' undeclared (first use in this > function) > dkim-filter.c:4538: error: (Each undeclared identifier is > reported only once > dkim-filter.c:4538: error: for each function it appears in.) > make[1]: *** [dkim-filter.o] Error 1 > make[1]: Leaving directory `/root/temp/new/dkim-milter-0.5.1 > /obj.Linux.2.6.10-2.3.legacy_FC2smp.i686/dkim-filter' > make: *** [all] Error 2 > > Any ideas on how to proceed? > > Thanks in advance > Michael Weiner > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make > your job easier > Download IBM WebSphere Application Server v.1.0.1 based on > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 |
From: SM <sm...@re...> - 2006-08-28 04:09:32
|
At 16:17 27-08-2006, Michael Weiner wrote: >Trying to build the latest version on a Fedora Core 2 server to >replace the v0.3.1 version i am currently running and i keep getting >the following build error: > >cc -O2 -I. >-I../../include -I../libdkim/ -DNO_SMFI_INSHEADER >-D_FFR_ANTICIPATE_SENDMAIL_MUNGE -D_FFR_FLUSH_HEADERS >-D_FFR_LOG_SSL_ERRORS -D_FFR_MULTIPLE_KEYS -D_FFR_REPORTINFO >-D_FFR_REQUIRED_HEADERS -D_FFR_SELECT_CANONICALIZATION >-D_FFR_SELECT_SIGN_HEADERS -D_FFR_SET_DNS_CALLBACK >-D_FFR_SET_REPLY -D_FFR_VERIFY_DOMAINKEYS -D_REENTRANT >-DXP_MT -c -o dkim-filter.o dkim-filter.c >dkim-filter.c: In function `main': >dkim-filter.c:4538: error: `cf' undeclared (first use in this function) Remove the -D_FFR_FLUSH_HEADERS. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2006-08-28 17:55:14
Attachments:
PATCH
|
Actually Ben got it right. The problem is actually with _FFR_SELECT_SIGN_HEADERS. There's a typo in a variable name. This was reported by someone else back in June, but I haven't released a new version since then. Try the attached patch. |
From: Mark M. <Mar...@ij...> - 2006-08-28 18:17:45
|
Murray, > Actually Ben got it right. The problem is actually with > _FFR_SELECT_SIGN_HEADERS. There's a typo in a variable name. This was > reported by someone else back in June, but I haven't released a new version > since then. Try the attached patch. Is there a chance that the problem reports 1544301 and 1537905 get fixed in a forseeable future? The postfix community became quite interested in dkim-milter (and dk-milter) with the introduction of a milter protocol support in Postfix 2.3, and, as a saying goes, strike while the iron's hot :) Regards Mark |
From: Murray S. K. <ms...@se...> - 2006-08-28 20:13:53
|
Mark Martinec wrote: > Is there a chance that the problem reports 1544301 and 1537905 > get fixed in a forseeable future? The postfix community > became quite interested in dkim-milter (and dk-milter) with > the introduction of a milter protocol support in Postfix 2.3, > and, as a saying goes, strike while the iron's hot :) I noticed all your reports from testing. I do want to get a new version out that handles as much of that as I can, modulo the pending overhaul of some of the code to do stuff like deal with multiple signatures. It's just a matter of getting a big enough chunk of time to do so. Patches are certainly welcome to help me out until I can get to it! -MSK |
From: Michael W. <hu...@us...> - 2006-09-13 01:46:41
|
I apologize for taking so long to get back to all of you, and again, thank you for your efforts. I tried Ben's suggestion as well as the patch provided by Murray - neither did the trick. So, how did i manage to correct this? well i re-extracted the archive, and went through the dkim-filter/Makefile.m4 carefully, and discovered i could build the milter with no problems until i enabled -D_FFR_ANTICIPATE_SENDMAIL_MUNGE option. Even with the supposed variable mispelling (which by the way i am unconvinced its wrong looking through the dkim-milter.c source). So i have all FFRs enabled but the above and the -D_FFR_VERIFY_DOMAINKEYS, and of course the -DNO_SMFI_INSHEADER - i always left these latter two disabled, Other than that i made no other changes from my original build attempts that i posted the error from. Thanks again for the help. The build appears to be at least working, though i need to complete my testing. Michael Weiner -- |
From: Murray S. K. <ms...@se...> - 2006-08-31 17:38:42
|
Mark Martinec wrote: > Is there a chance that the problem reports 1544301 and 1537905 > get fixed in a forseeable future? The postfix community > became quite interested in dkim-milter (and dk-milter) with > the introduction of a milter protocol support in Postfix 2.3, > and, as a saying goes, strike while the iron's hot :) Looking at 1537905 I see that you're asking that dkim-milter not try to get the job ID until after the first recipient. However, the call to smfi_getsymval() for the "$i" macro doesn't occur until the mlfi_eoh() callback which is certainly after the recipients are declared. Can you please clarify? (I'd add this remark to the bug but SourceForge is in read-only mode at the moment.) -MSK |
From: Murray S. K. <ms...@se...> - 2006-08-31 21:53:09
|
Murray S. Kucherawy wrote: > Mark Martinec wrote: >>Is there a chance that the problem reports 1544301 and 1537905 >>get fixed in a forseeable future? The postfix community >>became quite interested in dkim-milter (and dk-milter) with >>the introduction of a milter protocol support in Postfix 2.3, >>and, as a saying goes, strike while the iron's hot :) > > Looking at 1537905 I see that you're asking that dkim-milter not try to get the > job ID until after the first recipient. However, the call to smfi_getsymval() > for the "$i" macro doesn't occur until the mlfi_eoh() callback which is > certainly after the recipients are declared. > > Can you please clarify? I got the information I needed out of Wietse. The URL you included in the bug report is a little misleading to people coming from the sendmail side of things and thus don't understand the subtle nuances of the postfix implementation of milter. At any rate, those two bugs have now been updated with patches for you to try. I can push a v0.5.2 release after I get some test reports back about those and some other patches I mailed out to people privately. |
From: Mark M. <Mar...@ij...> - 2006-09-04 12:54:55
|
Murray S. Kucherawy wrote: >> Can you please clarify? > I got the information I needed out of Wietse. The URL you included in the > bug report is a little misleading to people coming from the sendmail side > of things and thus don't understand the subtle nuances of the postfix > implementation of milter. Thanks for your effort. I missed your previous posting until it was already resolved, sorry. Works fine now! > At any rate, those two bugs have now been updated with patches for you to > try. I can push a v0.5.2 release after I get some test reports back about > those and some other patches I mailed out to people privately. As posted on the SF ticket, the second patch is not yet good enough. Looking at the code, my feeling is that the interaction between automatic determination of LF vs. CRLF line endings, and processing the string one character at a time, makes a tough job, and other inconsistencies are likely. Like handling a bare CR within a line (although it is not allowed, it is up to a MUA to follow (or not) the rules). Perhaps a state-tranition automaton could be used. Doesn't milter always terminate lines in CRLF? Mark |
From: Murray S. K. <ms...@se...> - 2006-09-05 19:58:56
|
Mark Martinec wrote: > Doesn't milter always terminate lines in CRLF? Nope. If for example you're typing at sendmail from the command line (e.g. just "sendmail" or "sendmail -t" rather than an SMTP injection of some kind), CRs aren't added. I'll take another run at it shortly. |
From: Murray S. K. <ms...@se...> - 2006-09-11 23:07:00
|
Mark Martinec wrote: > As posted on the SF ticket, the second patch is not yet good enough. I just tested it, and it does appear to work but only if the line endings are LF vs. CRLF. I'll investigate further today. |
From: Murray S. K. <ms...@se...> - 2006-09-13 01:22:15
|
On Mon, 4 Sep 2006, Mark Martinec wrote: > As posted on the SF ticket, the second patch is not yet good enough. I just posted a revised patch. It turns out the MTA does indeed translate LF-terminated lines to CRLF-terminated lines, so all that adaptive clutter can go away. That made fixing that case simpler. Let me know how it goes. I'm going to be on vacation after this week so I'd like to get a patch out before then if possible. |