ietf-mta-filters
[Top] [All Lists]

Re: sieve draft

1997-11-01 21:20:45
On Nov 1, 11:07pm, Tomas Fasth wrote:
} Subject: Re: sieve draft
}
} Bart Schaefer wrote:
} > 
} > ... an email customer support service.  Customers with paid support can
} > legitimately send mail to support(_at_)supporters(_dot_)com(_dot_)  All 
other messages
} > sent to that address are bounced, with the suggestion that they pay up.
} 
} IMO, your example above is not a subject for delivery refusal.  [...]
} I suggest that a good design would be, from the MTA's point of view,
} to regard the message as being successfully delivered to the maildrop,
} which happens to have a service associated to it, a service which then
} decides by it's own access control whether to accept the service request
} or not.

It's certainly possible to handle it that way.  However, note that there
are nonzero costs associated with accepting delivery.  If the typical
message to my hypothetical support service contains a many-megabyte
coredump (and I have direct experience with users who mail such things
to support addresses), I'd much rather refuse delivery altogether than
have to consume the bandwidth to accept the message and then discard it.

My point is not that this is the best or only way to manage such a system,
merely that the bounce capability provides a useful alternative.  Whether
to permit it should be an administrative decision of the MTA maintainer,
not a decision of the language design -- unless there are other technical
reasons to omit it from the language.

Hmm; having written that, I see that as presently written the sieve draft
assumes that the message has already been "accepted" and that the bounce
action merely resends it via a DSN.  In that case I agree that "bouncing"
the message is much less interesting as a separate action.  However, I'm
not convinced that there aren't valid reasons to want to use a DSN rather
than an MDN to describe what has occurred.

} I would not recommend to make that kind of handling a business of the
} MTA. It would only be confusing and even hard to administer and
} maintain.

Why would it be any harder to administer/maintain than a collection of
individual services?  Especially if there is simply a seive script to be
associated with each such address.

} > I subscribed to the fud-list(_at_)blather(_dot_)com mailing list, but now I 
don't
} > want it any more.  I've sent a dozen unsubscribe requests, but nobody
} > is managing the list and it keeps coming to me.  I want to bounce the
} > messages back to the (admittedly unresponsive) list admin address and
} > to the postmaster(_at_)blather(_dot_)com in hopes of getting their 
attention.
} 
} Hmm. In this case I think your approach is unfriendly.

Note that I'm assuming that repeated polite requests have failed.  However,
again it's not up to the language designers to decide what is or is not
"friendly."

} I do not consider that a good use of filtering.

That is not a technical reason to leave the capability out of the language.

} I suggest we begin by distinguish between message delivery and
} message acceptance. By doing this we might be able to reach some
} kind of consensus on what we are trying to achieve here.

I don't think there's any disagreement on the terms, merely on when it is
appropriate to refuse.  And those are matters of opinion, not definition.

} My point is that if we use this description as a model, message
} delivery is just about to find the correct maildrop. That makes
} the task of the MTA much less complicated.

The name of this mailing list *is* ietf-mta-filters.  Have we all decided
that we're not talking about MTA-level filtering any more?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

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