On Sat, Jan 16, 2021 at 04:48:22AM -0500, Viktor Dukhovni wrote:

> On Sat, Jan 16, 2021 at 08:14:34AM +0000, Alexander wrote:
> 
> > My goal is to conditionally select the relayhost based on the total size 
> > of the outgoing message. The rationale is that I'm using Amazon AWS SES 
> > for the most part. Alas, SES only accepts messages up to 10 MB in size 
> > (this includes images and attachments that are part of the message), and 
> > when the outgoing message exceeds that size, it will be bounced.
> > 
> > Any tips for filters or tools that would help me define another 
> > relayhost based on the outgoing message size would be greatly 
> > appreciated!
> 
> Since the queue manager has no mechanism for size-dependent selection of
> a default transport (with the help of trivial-rewrite), the only way
> handle this deterministically in Postfix is to shunt large messages into
> a separate instance, which can be done in a number of ways, but is not
> particularly simple or elegant.

For this to be naturally supported in Postfix, we'd need a new feature,
namely a variant of "FILTER" that overrides *just* the default_transport,
making it possible to use more general criteria than "sender-dependent"
for default_transport selection.

Possible design:

    1.  New access(5) verb taking an associated transport value that
        triggers such an override.
    2.  New queue-file record type holding the default-transport
        override.
    3.  Queue manager loads this record into memory in the same way
        as "FILTER".  If both are present, "FILTER" wins.
    4.  Queue manager sends its value along with all trivial-rewrite
        "resolve" requests.
    5.  trivial-rewrite uses this default transport rather than
        $default_transport when the destination domain is not
        in any of the more specific address classes, and there
        is no explicit transport(5) mapping for the recipient.

This would be primarily useful only when using a relayhost, subject to
secondary criteria to divert some messages to a different transport
and/or nexthop based on ad-hoc message features detected during
message reception.  The difference from "FILTER" is that messages
to local recipients are not affected.

I am not sure whether adding such a feature motivated by just the
presented use-case is warranted.

-- 
    Viktor.

Reply via email to