Re: bounce, mta, & mua (was Re: sieve draft)

On Nov 3,  5:05pm, Tim Showalter wrote:
} Subject: bounce, mta, & mua (was Re: sieve draft)
}
} So that is, for most users.
}       [a message in Sender MUA]->[Sender MTA]->
}               [Receiver MTA]->[{something}]->[Receiver MUA]

I believe the model that other IETF groups are aiming for is more like

        [Sender MUA] -> [Submission Agent] ->
            [chain of zero or more Transport Agents] ->
                [Delivery Agent] -> [Recipient MUA]

There is active work on separating message relay (as happens in the chain
of transport agents) from message submission.

However, I think both the Submission and Delivery agents are legitimately
considered part of the transport system.

} I consider the "something" to be part of the MTA because it is transferring
} the message.  But I really don't care.  My desire is that somewhere in
} "something" is a filtering agent.

My desire would be that filtering could be inserted at almost any stage.
If the result of the filter is that the message is going to be rejected
or rerouted, then better to catch it as early as possible before the bits
have crossed the wires.

However, it is true that the farther you get from the recipient MUA, the
less likely the user is to get control over the disposition of messages.
 
} On Sun, 3 Nov 1996, Tomas Fasth wrote:
} 
} Rationale: I don't understand the difference between MTA and MUA filtering.

I see two differences:

1.  An MTA may not have access to all the UA's mailboxes.

2.  An MUA can't reject/reroute at the transport protocol level.

} I believe the difference between MTA and MUA filtering, where the filtering
} agent has the entire message, is more or less meaningless.

The Seive draft is written with the assumption that filtering happens at
delivery time, so that it's already too late for (2).  But (1) remains a
problem:

} In a POP3 system where filtering has to be done where remote folders
} are stored, filtering is done by the client.  Both are equally capable
} of sorting mail into folders, generating a reply and submitting it to
} an SMTP server, of throwing the message away, and of generating a DSN.

The significant difference is that, even if the envelope sender in the
Return-Path is correct, the POP3 client has no access to the envelope
*recipients*.  In an ideal world, that makes little difference, because
every recipient has his own POP3 maildrop.  In the real world, POP3 drops
are sometimes overloaded to delivery messages to an entire domain, e.g.
as a "replacement" for UUCP.

Of course, there's little the Seive language can do about that, except
to make it easier for the ISP in such situations to provide server-side
filtering.

} Would making "bounce" optional help?

I don't think so.  One could still construct and send a DSN using other
seive tools, so making it optional just makes it more difficult to do
the action, not impossible.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com