ietf-mxcomp
[Top] [All Lists]

Re: Semantics: per user policy

2004-05-08 12:17:23

[Regarding allowing "some" remote users to send via other MTAs, using a local part or LHS match mechanism...]

--Alan DeKok <aland(_at_)ox(_dot_)org> wrote:
  How can the recipient distinguish such mail from forged spam?

  And even ignoring that, what percentage of roaming users behave in
such a way?


If we allow some users to send mail from outside/unknown MTAs, and not others, we are still leaving the door open a bit for some forgeries as well. But, I think it's important to note that this is a still a better situation to be in than not implementing LMAP at all... *most* forgeries would still be blocked.

One way to do this would be "exempt" certain localparts/lhs values from checking, or return an "unknown" value. However, another solution that might be interesting is to let each user specify his/her own mailers as needed (by IP, domain name, or reference to another ISP's LMAP record.)

In this case, you might allow user A to roam, but only using Earthlink, and user B to roam, but only using Megapath, or something like that. This would narrow the potential abuses down to where it's no longer useful to most forgers... they will want to move on to the next target in order to get their mail through.


--Jon Kyme <jrk(_at_)merseymail(_dot_)com> wrote:
Bill's organisation seems to value the use of the flat *and*
subdomain-ed address spaces. Perhaps they'd also value MARID as well as
continuing support for "undisciplined" roaming users. Unless MARID can
accomodate them, something will have to give. Perhaps the organisation
would require changes so that it might gain the benefit of MARID. Their
benefit, their cost?

...
If a domain-wide statement can't be formed, then the policy would have to
be limited to subdomains over which a consistent assertion can be made.
While a MARID language should be "sufficiently" expressive, it's not clear
that the costs of the expressiveness you require must be borne by the
wider community. I'm not saying that this shouldn't be so, but features
which are useful only to a minority will have a harder job getting into a
spec than those which are widely useful.


Jon is right, using a sub-domain or other related domain for those users would be a workaround in many cases, though it would provide a less-than-ideal workaround in most cases where a localpart check would be useful.

In terms of who bears the cost, you make a valid point that we should probably explore, not just for localpart's sake but for any features that are in disputed territory.

Here is the simple approach:
 1. Is the feature needed by all, or most, MARID records?
 2. Put it in.

Here is an alternate approach:
 1. Is the feature needed by all, or most, MARID records?  Put it in.
 2. Is the feature ...
      2a. needed by some few domains?
      2b. has no appropriate workaround?
      2c. not too costly to implement?
    If a-c are true, put it in.

In other words, if there are features which are only useful to a minority of domains, but in cases where it is, there is a pretty clear need and no clear workaround, should it be on the table and at least talked about in terms of cost?

I think my vote would be to classify features as Needed or Wanted, and postpone the decision on which ones to drop until we have a chance to actually talk about cost. If we haven't had a chance to talk about cost, it's probably premature to classify a feature as "too costly to be fair to those who don't need it."



As a footnote, here are some other applications that could be done easily with localpart lookups, and are difficult or impossible without it.

* Allow a fallback-to-unknown for most users, but publish a much stricter policy for administrative addresses, like postmaster, support, etc.

* If using a smart DNS server that allows rate-limiting, allow a few messages from a certain user, but change the answer to NO after the limit is reached.

* Turn on logging at the DNS server so you can see ahead of time, before turning on MARID, who the roaming users are and where they are sending from.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>