To be honest, I'm not sure that the MTA is usually in a position to
receive filtering commands from the recipient's MUA. An MUA usually
retrieves mail using POP3 or IMAP, not SMTP, which rather disconnects
it from the inbound MTA - which in large ISPs is frequently
disconnected from the outbound smarthost which the MUA *does* connect
to via SMTP.
A policy enforcement component might be implemented at the same point (or
perhaps *by*) an upstream MTA. In fact anything that does this job is, I
suppose, a MTA (or MDA) by definition.
This is how things are done in a WebMail system that I'm familiar with.
Message disposition is implemented by the delivery component of the MTA
software (somewhat) under the control of the user. A problem is that there
is no *standard* way to convey recipient policy back towards (not
necessarily *to*) the sender. So it's only possible to configure Policy
(MTA filtering) via the proprietary MUA software (in this example). If
someone chooses to use the account via "pine" (for instance) they lose the
ability to configure their "Spam Protection" / other filtering. i.e - this
can only be done via the web interface.
Also, it's not easy to propagate user policy beyond the terminal MTA (not
even to 2ndary MXs) since you're likely to be talking about heterogenous
MTA software.
A standard policy / consent expression mechanism would allow any MUA
implementing it to communicate with any other MTS component which also
implements it.
However, a logically separate MFA (Mail Filtering Agent) would perhaps
be plausible - SpamAssassin run in "spamd" mode might be an example of
this role. The MFA might be attached to the MTA, or be a plugin to the
MUA, or even reside on a separate server (potentially run by the ISP or
a third party) and be called by the MUA.
MFA = instance of "policy enforcement component" surely?
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg