[Top] [All Lists]

[Asrg] Re: 4d. Consent Framework - making it clearer

2003-10-01 04:10:29

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