------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1563
Summary: RFE: Support for binary data returned from
transport_filter
Product: Exim
Version: 4.84
Platform: All
OS/Version: All
Status: NEW
Severity: wishlist
Priority: medium
Component: Transports
AssignedTo: nigel@???
ReportedBy: rblayzor@???
CC: exim-dev@???
Currently Exim allows a transport_filter but expects data returned from the
pipe to be a valid RFC2822 formatted message. Because the filter can modify
the message and return a different size and different count of newlines
(transport_count and transport_newlines), the message size and newlines are
updated based on whats returned from the transport_filter. This works
perfectly assuming a message file is returned.
Assume the following:
transport_filter = /usr/bin/gzip
Which would return binary (non-message file) data. POP/IMAP programs can use
Zlib to support compressed message file formats on disk. If Exim is doing the
delivery with the above transport filter, all works as expected except the
compressed binary data will not be accurate based on the uncompressed file size
(RFC2822 message).
This becomes a problem because quotas and maildir tags (S=, W=) expect the
uncompressed message file size. A program like Dovecot assumes the compressed
message size on disk is transparent to the user and that the tags and quotas
should reflect that of the uncompressed size. Therefore we must set
transport_count and transport_newlines to the size passed to the
transport_filter which assumes that the filter does not modify the message
format in flight and just stores the binary (compressed) data to disk.
Doing so insures that transport_count & transport_newlines are the original
size and that those sizes are used in tags and quota updates.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
