headers
Brad "anomie" Jorsch | 2 Oct 2007 00:15
Picon
Gravatar

[Bug 606] New: Resent-Date headers are not correctly detected

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=606
           Summary: Resent-Date headers are not correctly detected
           Product: Exim
           Version: 4.67
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Unfiled
        AssignedTo: ph10 <at> hermes.cam.ac.uk
        ReportedBy: anomie <at> users.sourceforge.net
                CC: exim-dev <at> exim.org

This bug report is actually for version 4.68 (and possibly earlier versions),
but that is not currently an option in bugzilla.

Detection of a Resent-Date header is broken, resulting in a duplicate
Resent-Date header being added if a Date header follows all Resent-Date
headers.

The problem is in receive.c line 1916: date_header_exists is set or cleared
when either a Date or Resent-Date header is seen. The correct behavior is to
set or clear the flag only when the appropriate header is seen (depending on
the value of resents_exist):
  if(!resents_exist || is_resent) date_header_exists = TRUE;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brad "anomie" Jorsch | 2 Oct 2007 00:15
Picon
Gravatar

[Bug 607] New: Resent-Date and Resent-Message-ID should be prepended, not appended

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=607
           Summary: Resent-Date and Resent-Message-ID should be prepended,
                    not appended
           Product: Exim
           Version: 4.67
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Unfiled
        AssignedTo: ph10 <at> hermes.cam.ac.uk
        ReportedBy: anomie <at> users.sourceforge.net
                CC: exim-dev <at> exim.org

This bug report is actually for version 4.68 (and possibly earlier versions),
but that is not currently an option in bugzilla.

Resent-Message-ID and Resent-Date are added at the end of the message, instead
of the beginning. While it's clear that we're not trying to handle multiple
blocks of Resent-* headers, exim should at least prepend these new headers (as
called for by RFC 2822 section 3.6.6) rather than append them.

The attached patch attempts to do this. The changes in receive.c simply change
the header_add() calls to header_add_at_position(). The changes in header.c
prevent the insertion of the Resent-* headers before the Received header that
is being generated at the same time; possibly there is a better way to fix this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brad "anomie" Jorsch | 2 Oct 2007 00:17
Picon
Gravatar

[Bug 607] Resent-Date and Resent-Message-ID should be prepended, not appended

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=607

--- Comment #1 from Brad "anomie" Jorsch <anomie <at> users.sourceforge.net>  2007-10-01 23:17:10 ---
Created an attachment (id=211)
 --> (http://bugs.exim.org/attachment.cgi?id=211)
The patch mentioned

(the attachment upload failed the first time)

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Magnus Holmgren | 2 Oct 2007 01:07
Picon
Picon
Picon
Favicon

[Bug 606] Resent-Date headers are not correctly detected

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=606

Magnus Holmgren <holmgren <at> lysator.liu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Unfiled                     |Mail Receipt
            Version|4.67                        |4.68

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Magnus Holmgren | 2 Oct 2007 01:09
Picon
Picon
Picon
Favicon

[Bug 607] Resent-Date and Resent-Message-ID should be prepended, not appended

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=607

Magnus Holmgren <holmgren <at> lysator.liu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Unfiled                     |Mail Receipt
            Version|4.67                        |4.68

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Tom Kistner | 2 Oct 2007 11:03
Favicon

Re: DKIM support

Magnus Holmgren wrote:

> So if I'm not mistaken, ignoring the issue of building on Linux (I solved
> that in a more minimal way, so to speak) and the nowsp compatibility 
> canonicalization code, it all boils down to the following?

Yeah thats it. Just the bare minimum we need to look up a result by 
domain (or identity, and even that is conflated right now). The problem 
is that the lib already tries to make a decision. We just want all the 
relevant info (results, policies) handed back to Exim and roll our own 
decision-making logic in Exim ACL "language".

The lib itself is OK - nice small footprint. Just the verification 
result API needs to be further extended. Signing looks OK as it is now.

/tom

> diff -w -xdebian -ur libdkim-1.0.14/src/dkim.h libdkim-1.0.15-tk/src/dkim.h
> --- libdkim-1.0.14/src/dkim.h	2007-05-03 17:53:09.000000000 +0200
> +++ libdkim-1.0.15-tk/src/dkim.h	2007-09-28 13:08:04.000000000 +0200
>  <at>  <at>  -137,6 +137,8  <at>  <at> 
>  { 
>  	char *szSignature; 
>  	char *DNS; 
> +       char *Domain; 
> +       char *IdentityDomain; 
>  	int nResult; 
>  } DKIMVerifyDetails; 
>   
> diff -w -xdebian -ur libdkim-1.0.14/src/dkimverify.cpp libdkim-1.0.15-tk/src/dkimverify.cpp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brad "anomie" Jorsch | 2 Oct 2007 16:39
Picon
Gravatar

[Bug 242] "control=no_pipelining" for connect and EHLO ACLs

------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=242

Brad "anomie" Jorsch <anomie <at> users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Brad "anomie" Jorsch <anomie <at> users.sourceforge.net>  2007-10-02 15:39:30 ---
This has been implemented in 4.67. Bug #372 exists for the "general control of
EHLO responses".

-- 
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 0 comments |
headers
Pixel // pinterface | 5 Oct 2007 04:11
Picon

[Bug 608] New: ACL condition with deny called from acl_smtp_quit/ acl_smtp_notquit causes error

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=608
           Summary: ACL condition with deny called from
                    acl_smtp_quit/acl_smtp_notquit causes error
           Product: Exim
           Version: N/A
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: bug
          Priority: low
         Component: ACLs
        AssignedTo: ph10 <at> hermes.cam.ac.uk
        ReportedBy: pinterface <at> gmail.com
                CC: exim-dev <at> exim.org

Given a setup such as the following
  acl_deny:
    deny

  acl_smtp_notquit:
    accept acl = acl_deny
    warn logwrite = How rude!

The exim log will contain
  ACL for not-QUIT returned ERROR: "deny" is not allowed in a QUIT 
  or not-QUIT ACL
rather than
(Continue reading)

Permalink | Reply | 4 comments |
headers
Graeme Fowler | 5 Oct 2007 10:36

[Bug 608] ACL condition with deny called from acl_smtp_quit/ acl_smtp_notquit causes error

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=608

Graeme Fowler <graeme <at> graemef.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |graeme <at> graemef.net
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Graeme Fowler <graeme <at> graemef.net>  2007-10-05 09:36:22 ---
A "deny" in the quit or not_quit acl is superfluous - at this point, the remote
server has either closed the connection gracefully (ie. sent a QUIT) or has
terminated unexpectedly, perhaps due to a network problem or (in the case of
Exim) by dropping the connection on purpose.

This is why the log message says:

ACL for not-QUIT returned ERROR: "deny" is not allowed in a QUIT or not-QUIT
ACL

This is documented here:

http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECTQUITACL

The ACL for the SMTP QUIT command is anomalous, in that the outcome of the ACL
does not affect the response code to QUIT, which is always 221. Thus, the ACL
(Continue reading)

Permalink | Reply | 2 comments |
headers
Graeme Fowler | 5 Oct 2007 11:06

Bugzilla's default assignee

...is still Phillip. Should that be changed now?

Graeme

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##
Permalink | Reply | 1 comment |

Gmane