https://bz.apache.org/SpamAssassin/show_bug.cgi?id=6918
Alessandro Vesely <ves...@tana.it> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ves...@tana.it
--- Comment #4 from Alessandro Vesely <ves...@tana.it> ---
I agree with Henrik, except for missing a curly brace:
--- AuthRes.pm.old
+++ AuthRes.pm.new
@@ -179,7 +179,7 @@
});
$conf->{parser}->register_commands(\@cmds);
-}
+
=item authres_ignored_authserv authservid1 id2 ... (default: none)
@@ -205,6 +205,7 @@
}
}
});
+}
=head1 METADATA
(perhaps sooner or later I'll find out how to commit.)
Longer rumination (written before Henryk's post):
The bugs referenced in comment #2 are about placing A-R fields before or after
Received. That's no usability problem. My MTA, for example, places some A-R
fields before and some after Received, depending on which process reports what
result. Much like X-Spam-* fields, admins know how ingress filtering works and
need to configure ADMINISTRATOR OPTIONS accordingly. In order to take into
account A-R fields placed before Received, authres_networks needs to be set to
"all", relying on authservid's if needed.
The only issue is to explain that in Mail::SpamAssassin::Conf.
I don't see why opendkim would create "quite simple" Authentication-Results.
>From a mailing list which I know uses OpenDKIM, I got:
Nov 12 18:38:45.003 [26569] dbg: authres: parsing Authentication-Results:
ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
header.b=kbJdZYzc; dkim=pass (1536-bit key) header.d=taugh.com
header.b=LwXl016e
Use of that result should be done in DKIM.pm, probably _check_dkim_signature,
instead of looking up everything from scratch. Ditto for SPF.
--
You are receiving this mail because:
You are the assignee for the bug.
