Recent changes to feature-requests

Add support for Vbr-Info header

2010-11-18T12:28:35Z

This is defined in RFC 5518 :http://www.rfc-editor.org/rfc/rfc5518.txt
That would be particulary useful on outgoing messages. While this header could be added by some MTAs, it seems that the DKIM signing program is the best place to inseert the Vouch By Reference header. See the RFC for more details.

Thanks

granularity compatibility - suggestion by dkim-deployment

2010-06-08T12:24:14Z

The draft-ietf-dkim-deployment makes a compatibility suggestion,
perhaps it could be incorporated into Mail::DKIM.

http://tools.ietf.org/id/draft-ietf-dkim-deployment-11.txt

A.1.2.3. DNS Selector Key Records

The format of the DNS key record was intentionally meant to be
backwardly compatible between DK and DKIM, but not necessarily
upwardly compatible. DKIM has enhanced the DK DNS key record format
by adding several optional parameters, which DK needs to ignore.
However, there is one key difference between DK and DKIM DNS key
records: the definitions of the g fields:

g= granularity of the key In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. For DK, an empty field is
the same as a missing value, and is treated as allowing any
sending address. For DKIM, an empty field only matches an empty
local part.

v= version of the selector It is advised that a DKIM selector have
"v=DKIM1;" at its beginning, but it is not required.

If a DKIM verifier finds a selector record that has an empty "g"
field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
beginning, it is faced with deciding if this record was

1. from a DK signer that transitioned to supporting DKIM but forgot
to remove the "g" field (so that it could be used by both DK and
DKIM verifiers), or

2. from a DKIM signer that truly meant to use the empty "g" field
but forgot to put in the "v" field. It is advised that you treat
such records using the first interpretation, and treat such
records as if the signer did not have a "g" field in the record.

implement reset() for Signer object

2010-03-31T21:02:16Z

See CPAN RT ticket 47925.

Use case:

If we want to use the same signer (meaning the same key, the same
domain/selector, the same algrithm/method) to sign different message, we
would have to have a reset() function in Mail::DKIM::Signer.

--- lib/Mail/DKIM/Signer.pm 2009-06-02 10:24:55.000000000 -0700
+++ /usr/lib/perl5/site_perl/5.8.0/Mail/DKIM/Signer.pm 2009-07-15
09:59:05.0000
@@ -174,6 +174,13 @@
}
}

+sub reset
+{
+ my $self = shift;
+
+ $self->SUPER::init;
+}
+
sub finish_header
{
my $self = shift;

The test case is attached.

Log to separate syslog file

2010-03-08T14:06:49Z

Hi,

I try to log to a seperate syslog file for dkimproxy.out (it would be
the same as the second postfix instance, responsible for outgoing
traffic), but didn't fine any configuration directives for syslog.

Any help is welcome,
Thanks,
Thomas

generate t= field (signature timestamp) on DKIM signatures

2009-10-26T16:15:17Z

Jason Long <jlong@messiah.edu> writes:

> 牛粥 wrote:
>> Signature Timestamp ("t=" field) is just optional. By the way, i wish to
>> add that into DKIM-Signature. For a while, i thought that "t=" field
>> will give folks the greatest confidence.
>
> This will require modification (patches welcome) to the Mail::DKIM
> library and the DKIMproxy program, since it currently does not have
> the programming needed to generate those timestamps.
> Jason

Test suite not depending on Internet connectivity

2009-08-01T16:37:31Z

It would be nice if you could let policy.t and public_key.t share the "fake DNS" in verifier.t, such that the test suite doesn't depend on the Internet being available.

(The build environment on Debian's autobuilders doesn't provide network connectivity, and anyway, Internet connections fail now and then and I don't think that should cause unit tests to fail.)

Create "dkim_method", "domainkeys_method" options

2009-07-30T14:18:05Z

For each of the main signing options, keyfile, selector, algorithm, and method (and domain and identity?), create additional options prefixed with domainkeys_ and dkim_ that will apply only for that signature type.

E.g. so instead of having to say "dkim(c=relaxed,a=rsa_sha256),domainkeys(c=nofws)" in the sender map file, I could specify --dkim_method=relaxed --dkim_algorithm=rsa_sha256 --domainkeys_method=nofws in the main config file, and then simply specify "dkim,domainkeys" in the sender map file.

Note: there is not currently an "algorithm" option. Since domainkeys only supports one algorithm, perhaps I can simply implement a dkim_algorithm option and not worry about making an "algorithm" option.

generate signature based on List-Id header

2009-07-28T13:39:01Z

Dear Jason,

Thanks muchly for your help. I spent some more hours but could not
solve the issue.
BTW, I have a friend who is running some dozen of mailing-lists also,
so we both need this signing feature based on List-ID's domain with
both DKIM and Domainkeys.
We think this feature would benefit a lot of people running mailing
lists around the world. As long as you are very kind to provide the
software as opensource. We'd like to ask if you have time/interest to
make a new feature available in dkimproxy? For example add a
configuration parameter (--addon-header=list-id) that tell dkimproxy
to sign emails based on the domain specified in the addon-header
field.
We'll be very happy if we can show our gratitude by donating money or
resource to the project, show the links to dkimproxy in our websites
and recommend our friends (for example FreeBSD community) to use
dkimproxy.

Please kindly let me know your opinion.

--
With best regards,
Chinh

Provide instructions for Upgrading

2009-07-12T12:11:38Z

To upgrade, all you need to do is download the new version, run ./configure with the same arguments as before, then make install,
then restart DKIMproxy.

But this should probably be spelled out in the INSTALL file (or in a new UPGRADE file).

More standard installation layout

2009-04-30T13:55:44Z

Currently, installing with --prefix=/usr/local/dkimproxy is recommended since it puts some files in $prefix/lib which might clobber other files.
I want to change things so that --prefix=/usr/local can be the default,
and the library files will be stored in /usr/local/lib/dkimproxy or something like that.

(This will make the man pages I'm working on show up at the right spot.)