------- 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: [email protected] ReportedBy: [email protected] CC: [email protected] 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
