-
Notifications
You must be signed in to change notification settings - Fork 52
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
rafork
wants to merge
129
commits into
trusteddomainproject:master
Choose a base branch
from
rafork:pr-issue-131
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Pr issue 131 #172
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
by Iosif Fettich.
_FFR_CONDITIONAL.
as a value delimiter.
…y contain a slash (which must be quoted).
…uplicate signatures, constrain the size of the resulting "header.b" value. Problem noted by Joseph Coffland.
…elds that are 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).
…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
Define __P() macro in libvbr
…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
miltertest: Fix broken mt.data() function
…kim-genkey-ed25519-support ed25519 support
were not being properly handled.
Update autoconf for 2.71
…aders/SenderHeaders/SignHeaders
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.