mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] Seeking consensus on MUA use

2008-12-12 16:24:24
On Fri, Dec 12, 2008 at 11:47:17AM -0800, Murray S. Kucherawy wrote:

It seems I need to re-confirm this group's consensus on a point of the 
draft as it proceeds through IESG evaluation.

The scope of this work has always been pretty narrow: We take the output 
of message authentication methods and relay them to MUAs

MUAs or (and perhaps more frequently) downstream filters.

so they can make 
their own filtering decisions based on those results.  None of the 
implementations in the four years of this work has found a need to deviate 
from that practice, so that really does define the scope of this work.

It has been suggested that an MUA might wish to make further evaluations 
based upon the IP address of the MTA relaying the message in to the border 
MTA and, therefore, this specification should enable that by including the 
relaying IP address as detected by the border along with all of the other 
result data.  That information could then be compared to blacklists or 
whitelists, used to query reputation, etc. by the MUA displaying the 
message.

The main problem with this, is that MUAs see messages multiple times,
potentially days, weeks or years later, and the IP reputation is pretty
useless at that point. So, for MUAs, it is the reputation and NOT the IP
that would be needed in the message, but of course the MTA does not know
which reputation systems to query in this context.

When we switch focus to downstream filters (not MUAs), these act in
real-time, and IP reputation is indeed relevant.

With Postfix in the environment I operate, the IP data is passed from
the edge filter to the filters via the Postfix-specific "XFORWARD"
SMTP command:

    http://www.postfix.org/XFORWARD_README.html

Perhaps this could be carried in headers instead, or perhaps the need
is better met by standardizing the better parts of the XFORWARD idea
to allow session context to be passed from edge MTAs to filters and
downstream MTAs.

The flow is:

    Postfix -> Post-queue-Spam-Filter -> Postfix -> Message-Store
                                          |
                                          |
                                          v
                                        Quarantine

The XFORWARD carries external IP and related data between the two Postfix
instances via the filter. The filter uses IP reputation and adds headers,
some headers cause the downstream Postfix to route mail to the Quarantine
instead of the Message-Store.

The specification as it stands is pretty clear in terms of its scope, 
namely the deployment experience to date.  Given that and the fact that 
it's extensible (so this could be added later if it's actually useful), 
I've been arguing the position that this isn't a good thing to add to the 
draft at this stage.  If someone really feels this would be a useful 
extension and wishes to deploy it, a new method could be registered which 
provides it.

What does the group think?

Don't know about the group, but I personally think that MUAs don't
need this, and would likely misuse it. Filters between the MUA and
MTA do need IPs for reputation lookups, but this specification may
not be the best vehicle.

-- 
        Viktor.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>