Alan,
ok. central registration and a centralized query service. initially a
single implementation.
AD> Yes. Edge deployments.
requiring a central server is not an 'edge' deployment.
AD> End-user work required to deal with RMX variants is similar. The
AD> end users install new software (SUBMIT client) which connects to a
AD> centralized service (ISP or business MTA).
I think that the origin of this sub-tread continue to be forgotten.
Note:
MCL> For that reason, it'd be better to come up with a recommendation whose
MCL> impact is largely, or completely, server-side, and transparent to the
MCL> client and end-users.
So, this is about claimed transparency and a counter-claims that RMX
approaches are a long way from being transparent to end-users.
You claimed that SPF imposes no user burden. The truth of that statement
does not hinge on whether other things impose a burden.
AD> If I did, it was either a mis-statement, or an unclear phrasing on
AD> my part.
my bad. MCL made the claim. Still, it was the basis for this
sub-thread.
AD> Many MTA administrators I know like RMX, if only because it permits
AD> them to read "postmaster" mail again. Lack of a useful "postmaster"
AD> has significant cost and stability issues for many domains.
Solutions that become unwieldly with large-scale use have their own cost
and stability issues, especially if their benefit is ephemeral.
Once again, a scheme that requires disabling the scheme, to support
significant, valid scenarios, is a very problematic scheme.
AD> It's not "disabling" the scheme. It's working within the scheme to
AD> acheive backwards compatibility with end-users who don't want to
AD> change their behaviour.
For the users with the problem, it renders the scheme useless, except
for creating hassles.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>