Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pr issue 131 #172

Open
wants to merge 129 commits into
base: master
Choose a base branch
from
Open

Pr issue 131 #172

wants to merge 129 commits into from

Conversation

rafork
Copy link

@rafork rafork commented Feb 28, 2023

This pull request addresses issue #131.

It adds statements in the manual entry that the OmitHeaders, OversignHeaders, SenderHeaders, SignHeaders parameters are comma-separated. This was not explicitly stated before.

It adds a statement in the manual entry explicitly listing which headers are included in the default value for the SignHeaders parameter. Previously, the manual entry incorrectly referred the user to RFC6376 and a list of headers that "SHOULD" be signed, although RFC6376 contains no such list. It only has a list of commonly-signed headers, and the default in OpenDKIM contains one extra header that is not in that list. Now, the manual entry informs the user exactly what the default is without requiring them to refer to RFC6376.

The config sample file has had fixes to the default values of some of these parameters, and it now has examples showing the use of the *,+header1,-header2 notation to modify the existing default.

Note: I asked if the above usage was actually valid, and haven't received an answer yet, but I think it must be valid usage, and so I have assumed for the moment that it is, and have created this pull request now rather than waiting for the answer. If it turns out not to be the case, I can modify this pull request by removing the examples that show that usage.

Murray S. Kucherawy added 30 commits May 10, 2015 23:05
constrain the size of the resulting "header.b" value.  Problem
noted by Joseph Coffland.
wrapped before there's any content.  Somehow the wrong fix
was committed.  Originally reported by Alessandro Vesely;
re-reported by David Stevenson.
…re object requests where

the domain name or selector includes non-printable characters.
Suggested by Franck Martin.
…l signature

request, probably with an "l=0" (at least for starters), rather than altering
an existing signature request.  Break the build until I fix it.
… it rather

than altering an existing one (you need both).
martinbogo and others added 30 commits June 4, 2020 10:40
…f-ip-caveats

opendkim.conf: Note more caveats for ip addresses

Documentation update, looks good.  Merging.
Definitions for this macro have been added throughout the codebase in
commits 91e7407, 705948f, 227fa25, 842c173, and b730bdc, but one
was still missing from libvbr. glibc contains a definition for legacy
reasons, but other libcs might not. Particularly, the musl libc does not
contain it, leading to build errors when enabling support for VBR.

Add a definition for __P() to vbr.h to fix this.
The upstream Lua pkg-config file is named lua.pc, so unless some
distribution renames it, OpenDKIM should be looking for "lua"
and not "lua5.1" in its PKG_CHECK_MODULES call. In any case, we
should definitely be checking for "lua", so this commit appends it
to the list of modules we look for. The "lua5.1" module was left
alone, because I don't know enough of the history to be sure that
removing it is the right thing to do.

When the call to PKG_CHECK_MODULES fails, OpenDKIM falls back to
a manual search that looks in /usr/lib, and this can detect 32-bit
libraries on a 64-bit system. Therefore it is preferable that the
PKG_CHECK_MODULES call succeed.

In the process of adding this fallback, I realized that some
additional actions need to be performed in the success branch of
the existing (and new) PKG_CHECK_MODULES call. The following
three lines were added,

  AC_SEARCH_LIBS([dlopen], [dl])
  AC_SUBST([LUA_MANNOTICE], "")
  AC_DEFINE([USE_LUA], 1, [support for Lua scripting])

to tell various parts of OpenDKIM that we do indeed have Lua support.
Afterwards, it became clear that those three lines could be factored
out of *every* lua check, so that has been done as well.

Closes: trusteddomainproject#62
Gentoo-bug: https://bugs.gentoo.org/704556
…key-man-restrict

opendkim-genkey(8): Fixed typo option "restricted" to "restrict"
…im-genzone-nodate

make the output comparable, avoid variable timestamp data
…hema_update2

make the ldap class STRUCTURAL and DKIMDomain subsearchable
…s-header

Add missing space in Authentication-Results header
…kgconfig-check

configure.ac: check for "lua" with pkg-config in addition to "lua5.1".
…im-genzone-logical-error-fix

logical-error-fix
…s-syslog

Suppress empty brackets in syslog startup message
Various minor fixes in sample opendkim.conf
…om-check

miltertest: Fix undefined behaviour in mt.eom_check() with MT_SMTPREPLY
…-callback

Plug memory leak in Unbound callback function
…perator-configure

Fix unknown operator in configure.ac
…kim-genkey-ed25519-support

ed25519 support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet