This library contains functions MTA's can use to create and verify mail header signatures of Yahoo'd domain key system. Although MARID group of IETF failed to setup an anti-SPAM standard, it is useful to play around with various solutions to get used to them. Patches for most MTA's is in ongoing development. see: http://domainkeys.sourceforge.net/
Created attachment 44141 [details] libdomainkeys-0.62.ebuild-package.tar.gz new ebuild package for llibdomainkeys-0.62 file-listing: ------------- libdomainkeys/ libdomainkeys/files libdomainkeys/files/digest-libdomainkeys-0.62 libdomainkeys/ChangeLog libdomainkeys/Manifest libdomainkeys/libdomainkeys-0.62.ebuild -------------
Created attachment 44204 [details] libdomainkeys-0.62.ebuild-package-r2.tar.gz Sorry, I have forgotten to install "dknewkey" and "dktest" in the ebuild.
Created attachment 47299 [details] libdomainkeys-0.62-r1.ebuild-package.tar.gz I found some problems with the default library and produces a patch. See http://sourceforge.net/tracker/index.php?func=detail&aid=1093952&group_id=107680&atid=648373 short summary: 1) header list "h=" is created with the signature 2) processing the header list during validation had some flaws. 3) introduced environment variable DKIGNORE to ignore some headers. qmail-scanner relacates its X-Spam-Status header if another server scanns the email. This brakes the signature. Therefore such headers should not be used to calculate the signature in NOFWS mode. a new package is attached.
Created attachment 47307 [details] libdomainkeys-0.62-r1.ebuild-package.tar.gz Thanks to my friend Axis, who found a myjor bug in my patch. I am so sorry, it must have been too late in the night so I have overseen this major bug. I have a new package attached.
Created attachment 47313 [details] libdomainkeys-0.62-r1.ebuild-package.tar.gz once more ...
Don't attach tarballs, please. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3
Created attachment 69544 [details] libdomainkeys-0.68.ebuild hacked together version for libdomainkeys-0.68. License is wrong. Correct License is "Yahoo! DomainKeys Public License" http://domainkeys.sourceforge.net/license/softwarelicense1-1.html Most apps supporting domainkeys require this lib. Adding it to portage would be great.
Created attachment 72443 [details] libdomainkeys-0.68-r1.ebuild libdomainkeys-0.68 is obsolete add dktrace.h to /usr/include
Is there any chance that this ebuild ever gets into the tree?
Unless some MTA actually makes use of it (and I don't mean MTA patched by 3rd party), I can't see how this is useful to have in portage, sorry.
I understand, but: exim has it since 4.51 as experimental feature (as well as SPF), see #111729 and doc/experimental-spec.txt qmail: see #88695 ("3rd party patching" is quite common in qmail: http://qmail.mirrors.space.net/top.html#addons)
Oftentimes people running gentoo servers (like me) run 3rd party applications that require various open source libraries. So it seems a silly requirement for a library to be used by another package in portage for it to make it into portage. And the exim point is well-made, which is what I need this particular library for, but I just don't think that not putting something in portage just because nothing else in portage currently needs it is a bit silly.
(In reply to comment #12) > Oftentimes people running gentoo servers (like me) run 3rd party applications > that require various open source libraries. So it seems a silly requirement > for a library to be used by another package in portage for it to make it into > portage. If we don't have an application using that library, how can we test to see if it works?
(In reply to comment #13) > If we don't have an application using that library, how can we test to see if > it works? Please see bug 111729: Exim has support for it and an ebuild is being readied.
libdomainkeys has been added to portage and support is now in exim-4.67 Please Accept my apologies for the delay. I'll let other MTA maintainers implement it if they want.
obsoleted by current available packages
