[exim-dev] [Bug 1563] New: RFE: Support for binary data retu…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Robert Blayzor
Datum:  
To: exim-dev
Neue Treads: [exim-dev] [Bug 1563] RFE: Support for binary data returned from transport_filter, [exim-dev] [Bug 1563] RFE: Support for binary data returned from transport_filter
Betreff: [exim-dev] [Bug 1563] New: RFE: Support for binary data returned from transport_filter
------- 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