Michael Haardt | 7 Oct 14:30 2008

Data retention with Exim

Hello,

I hate being forced to bring up this topic, but even if I would not,
"1984" is no longer fictional and I am sorry helping big brother:

I suggest a patch that introduces a new and optional log file that
carries all data required by the European data retention guideline.
The format of the Exim log may change and is not too well suited as
source for extracting what's needed.  The format of the new logfile will
not change and only store what is needed in a rather fixed manner.
That's the easiest interface I can imagine to allow each concerned
site reliably getting the data.

Should other laws require different details, we may have to add a log
format besides the option specifying the path.

The small patch is experimental and (for now) contained in #ifdefs for
not disturbing production builds, but allowing to share it with others
having the same problem.  A bunch people certainly require some solution
by the end of the year, although only one has asked on exim-users already.

Are there any non-political opinions against committing this patch?

Michael

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##

(Continue reading)

Nigel Metheringham | 8 Oct 13:08 2008

[Bug 768] Documentation Mistake

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

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

Nigel Metheringham <nigel <at> exim.org> changed:

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

--- Comment #1 from Nigel Metheringham <nigel <at> exim.org>  2008-10-08 12:08:35 ---
Your octets have no ambition!

Fixed in the wiki version - http://wiki.exim.org/FAQ/Miscellaneous/Q5033

We really need to scrub or maintain the original version - its been
languishing for years.

-- 
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/ ##

Mark Oakley | 8 Oct 12:37 2008
Picon

[Bug 768] New: Documentation Mistake

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

http://bugs.exim.org/show_bug.cgi?id=768
           Summary: Documentation Mistake
           Product: Exim
           Version: N/A
          Platform: Other
               URL: http://www.exim.org/
        OS/Version: Windows
            Status: NEW
          Severity: bug
          Priority: low
         Component: Documentation
        AssignedTo: nigel <at> exim.org
        ReportedBy: jmoakley <at> yahoo.co.uk
                CC: exim-dev <at> exim.org

From FAQ Q5003

if $sender_address_domain is mydomain.com and
   ${mask:$sender_host_address/24} is 192.168.324.0/24
then
  unseen deliver mailbox <at> whatever.domain
endif

The third octet of the network looks to be wrong. 324 is too big for an 8 bit 
field methinks.

--

-- 
(Continue reading)

Christof Meerwald | 10 Oct 09:36 2008

Re: Data retention with Exim

On Tue, 07 Oct 2008 14:30:48 +0200, Michael Haardt wrote:
> The small patch is experimental and (for now) contained in #ifdefs for
> not disturbing production builds, but allowing to share it with others
> having the same problem.  A bunch people certainly require some solution
> by the end of the year, although only one has asked on exim-users already.
>
> Are there any non-political opinions against committing this patch?

The patch doesn't appear to have made it to the list (at least not to the
mail archive or gmane). Can you make that patch available or send it to me
off-list?

Personally, I would think that exim should be able to cope with these kind
of things, but I would prefer to have a generic solution.

Christof

-- 

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##

Graeme Fowler | 10 Oct 10:54 2008
Picon

Re: Data retention with Exim

Hi

On Tue, 07 Oct 2008 14:30:48 +0200, Michael Haardt wrote:
> Are there any non-political opinions against committing this patch?

Unfortunately separating the political and technical at this point is
quite difficult, in my opinion, which I'll explain below.

On Fri, 2008-10-10 at 09:36 +0200, Christof Meerwald wrote:
> Personally, I would think that exim should be able to cope with these kind
> of things, but I would prefer to have a generic solution.

Exim can already log far more data than it does by default - the
log_selector config option allows for a bundle of information:

http://www.exim.org/exim-html-current/doc/html/spec_html/ch49.html#SECTlogselector

Given that each member state of the EU can modify the Directive
2006/24/EC to fit their own ends (which in fact the UK govt has done)
it's my belief that providing a fixed format which "fits" is not the job
of the application, but the job of the sysadmin running the application.

In the case of Exim it seems that according to Article 5 of the
directive, the requirements are already fulfilled by the default log
format - this logs:

  sending and destination IP
  sending envelope email address
  all recipients, whether to/cc/bcc or envelope
  time
(Continue reading)

Chris Edwards | 10 Oct 16:42 2008
Picon
Picon

Re: Data retention with Exim

On Fri, 10 Oct 2008, Graeme Fowler wrote:

| Given that each member state of the EU can modify the Directive
| 2006/24/EC to fit their own ends (which in fact the UK govt has done)

I'm not totally clear about this aspect.  Member states can choose the 
period for which data is retained (between 6 months and 2 years).  
But is there local scope to change which fields must be retained ?

Article 5 says "Member States shall ensure that the following categories 
of data are retained" which I guess means requiring more is an option 
but not less.

| it's my belief that providing a fixed format which "fits" is not the job
| of the application, but the job of the sysadmin running the application.

Agreed.

And as you say, it looks like all the info that might be wanted is already 
logged by default.  Without having seen Michael's patch, I can't comment, 
but perhaps he means a log which has LESS info than the default ie. ONLY 
that required by law.

No doubt this might also be achieved by suitable post-processing.

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##

(Continue reading)

Florian Weimer | 10 Oct 17:17 2008
Picon

Re: Data retention with Exim

* Chris Edwards:

> | Given that each member state of the EU can modify the Directive
> | 2006/24/EC to fit their own ends (which in fact the UK govt has done)
>
> I'm not totally clear about this aspect.  Member states can choose the 
> period for which data is retained (between 6 months and 2 years).  
> But is there local scope to change which fields must be retained ?

Yes.  Germany's implementation requires that you log both addresses
(original and new) when you perform address rewriting.

> Article 5 says "Member States shall ensure that the following categories 
> of data are retained" which I guess means requiring more is an option 
> but not less.

Seems so.

-- 
Florian Weimer                <fweimer <at> bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra├če 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

--

-- 
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at
http://www.exim.org/ ##

Richard Godbee | 12 Oct 03:36 2008
Picon

[Bug 769] New: extraneous comma in fprintf() in exim_usage()

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

http://bugs.exim.org/show_bug.cgi?id=769
           Summary: extraneous comma in fprintf() in exim_usage()
           Product: Exim
           Version: 4.69
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: bug
          Priority: low
         Component: General execution
        AssignedTo: nigel <at> exim.org
        ReportedBy: richard <at> godbee.net
                CC: exim-dev <at> exim.org

Created an attachment (id=278)
 --> (http://bugs.exim.org/attachment.cgi?id=278)
remove unneeded comma in fprintf() statement

One of the fprintf() statements in exim_usage() contains two strings separated
by a comma, so they are treated as separate arguments to fprintf().  The comma
should be removed so the two strings are concatenated and treated as a single
argument.  (Patch attached.)

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

--

-- 
(Continue reading)

Nigel Metheringham | 12 Oct 12:02 2008

[Bug 769] extraneous comma in fprintf() in exim_usage()

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

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

Nigel Metheringham <nigel <at> exim.org> changed:

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

--- Comment #1 from Nigel Metheringham <nigel <at> exim.org>  2008-10-12 11:02:16 ---
Committed fix, but due to my inadequacy or the cvs scripts getting it wrong
failed to close off bug at same time.

See
  http://vcs.exim.org/viewvc/exim/exim-src/src/exim.c?r1=1.60&r2=1.61
  http://vcs.exim.org/viewvc/exim/exim-doc/doc-txt/ChangeLog?r1=1.554&r2=1.555

-- 
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/ ##

Maxim Dounin | 13 Oct 16:01 2008
Picon

[Bug 770] New: Daemon should reinitialize len before calling accept()

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

http://bugs.exim.org/show_bug.cgi?id=770
           Summary: Daemon should reinitialize len before calling accept()
           Product: Exim
           Version: 4.69
          Platform: All
        OS/Version: FreeBSD
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Networking
        AssignedTo: nigel <at> exim.org
        ReportedBy: mdounin <at> mdounin.ru
                CC: exim-dev <at> exim.org

Created an attachment (id=279)
 --> (http://bugs.exim.org/attachment.cgi?id=279)
reinitialize len before calling accept()

In src/daemon.c, initialization for len argument of accept() syscall is done
only once per loop over active listening sockets.  As a result if operation
system modifies len for some reason, for next socket accept() may be called
with invalid value of len.

At least FreeBSD resets len to 0 on error returned from accept() - and it may
happend e.g. on ECONNABORTED (i.e. client timed out before exim accepted
connection).

(Continue reading)


Gmane