------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1030
Todd Lyons <tlyons@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tlyons@???
--- Comment #1 from Todd Lyons <tlyons@???> 2010-10-14 18:28:50 ---
In my mind, "broken_headers" means more than one header when the spec
mandates only one, however it's likely that a better label could be
created. I'm just not that creative. In all of the comments below,
I'm not requesting that these names or labels be used, but rather am
trying to indicate how I would expect to see the knobs I would turn
and what the desired behavior is.
1. Global options for reject_broken_headers
yes
no
quarantine (debugging)
With this global option, the stage is set for being really strict,
doing nothing, or saving a copy for debugging purposes. I would
really only expect the quarantine to be useful for developers, not
used in a production system.
2. ACL support for reception/relaying
control = broken_headers/fix_use_first
control = broken_headers/fix_use_last
control = broken_headers/no_fix
I kind of have a problem with these. I can't explain it, it just
doesn't feel like the right way to deal with it. However, this is
precisely where DKIM verification will need the help. Oh, and the
fixed headers obviously must be what is made available to the
transport that does the dkim signing. You need to prevent the
reception/relaying of RFC 5322 malformed emails here.
3. ACL support for submission
control = submission/fix_broken_headers_use_first
control = submission/fix_broken_headers_use_last
control = submission/no_fix_broken_headers
Arguably, any of these could be the default for local_fixups, and
no_fix_broken_headers could be implied by suppress_local_fixups.
This has no bearing on DKIM verification, but will be useful in a
security context because you are restricting the user from sending
emails that are attempting to exploit/abuse this DKIM signing
issue. Technically this is an MUA vulnerability, because $MUA
shows the wrong header (in the case of the duplicated From). It's
a $MTA issue according to some because an email that violates RFC
5322 by having improper headers should not be relayed unaltered.
It's a DKIM issue only because $MTA allows malformed messages
through and $MUA displays the malformed data incorrectly, for
some (most? all?) values of $MTA and $MUA (sendmail and gmail in
my case).
4. Result variables
$broken_headers
$broken_headers_list
$broken_headers_description
The $broken_headers var is a read-only var that can be 1 or 0,
and can be used to decide whether to sign an email or not (if
global is set not to reject) and/or to decide to strip
signature headers or auth results headers. The
$broken_headers_list could be a standard list of headers which
are broken. The $broken_headers_description could be a terse
description suitable for use in logs or rejection messages.
Sample text:
Invalid headers found in email
or
Invalid headers found in email (h1,h2,h3)
where the headers are the header names, not the counts or what
was wrong with them.
5. Detailed results
$broken_header_NAME or $broken_h_NAME
By iterating through $broken_headers_list or just checking the one
you want to check such as ${if def:broken_h_NAME ... }, you can
get very detailed descriptions of how the header was broken. This
could also allow you to get past the concept of "more than one" as
the reason for being broken.
Sample text:
Found X NAME headers, but RFC 5322 mandates can only be 1.
or
Missing Date header, RFC 2822 requires it to be present.
6. I don't have an opinion on the concept of a method that is like
malware=*. It seems like it would combine #2 and #3 above, but it
removes the separate reception/relaying and submission capabilities.
I'm having trouble visualizing this implementation.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
