> >
> > If the sender gets a tempfail for anything other than RCPT TO, I would
> > not expect the sender to split the resend, in fact, it's highly
> > unlikely.
>
> Right.
There were a variety of ESMTP proposals kicked around ASRG concerned with
putting the data before the recipient list; AFAIK n
On 2008-01-28 15:15:26 -0500, Chris Lewis wrote:
> Jared Johnson wrote:
> >Peter J. Holzer wrote:
> >>That's why I wrote cf_wrapper (it's in the contrib directory), which
> >>checks the results for all recipients and returns a temporary error when
> >>they don't agree - when the client resends the
On 2008-01-28 13:34:18 -0600, Jared Johnson wrote:
> Peter J. Holzer wrote:
> >That's why I wrote cf_wrapper (it's in the contrib directory), which
> >checks the results for all recipients and returns a temporary error when
> >they don't agree - when the client resends the message, it can "split"
>
Chris Lewis wrote:
Jared Johnson wrote:
Peter J. Holzer wrote:
That's why I wrote cf_wrapper (it's in the contrib directory), which
checks the results for all recipients and returns a temporary error when
they don't agree - when the client resends the message, it can "split"
them into two group
Jared Johnson wrote:
Peter J. Holzer wrote:
That's why I wrote cf_wrapper (it's in the contrib directory), which
checks the results for all recipients and returns a temporary error when
they don't agree - when the client resends the message, it can "split"
them into two groups with consistent re
Peter J. Holzer wrote:
That's why I wrote cf_wrapper (it's in the contrib directory), which
checks the results for all recipients and returns a temporary error when
they don't agree - when the client resends the message, it can "split"
them into two groups with consistent responses.
Who is "the
On 2008-01-25 15:03:58 -0600, Jared Johnson wrote:
> >One way to approach it could be to leave the current transaction
> >object intact but add a method to say/query "do the recipients
> >individually" and then have a method to access the individual ones.
> >That way we can move plugins that need t
One way to approach it could be to leave the current transaction
object intact but add a method to say/query "do the recipients
individually" and then have a method to access the individual ones.
That way we can move plugins that need the extra information to use it
and the ones that don't care to
On Jan 25, 2008, at 11:49, Jared Johnson wrote:
I'm wondering, is there some supported, "right" way to basically
clone a transaction so that I can modify aspects of it like the
message body and/or subject for one list of recipients while leaving
it intact in the original transaction obje
