On 2/6/2010 12:38 PM, John R Levine wrote:
A large mail hosting company with thousands of POP and IMAP
customers should be the ideal environment for an MUA spam button,
particularly since they already have a button in their web mail.
But the scenario you put forward is far more specialized that this description.
A "large mail hosting company that lets each of its customers configure domain
names for their retrieval host" is pretty bloody unusual.
Offhand, your model seems to be confusing public domain names -- such as what
others send email to -- from internal names, such as what is used between the
hosting service and their direct clients.
Again, I'm not saying that the scenario you put forward is wrong or even a poor
choice. Merely that the more distributed the control, the more likely that
changes to the operation will have a more distributed effect.
Basically, with an environment of the sort you describe, everything is
relatively more difficult.
That hasn't been my experience. They make all sorts of changes, but they
don't make changes that require every reseller to change the DNS for
every customer.
It's always nice to have scaling effects where massive increases in scale do not
require significant increases in operations effort. But it's not mandatory.
While it's fine to try to design something so that it's scaling
characteristics are /better/ than linear, but it's typically also
acceptable for it to be linear.
I really don't understand all the resistance to a header applied by the
MDA.
For one thing, it introduces a somewhat more complicated trust model, and
probably introduces some undesireable security edge conditions.
Yes, this will require a one-time change to the MDA, but you get a
much more solid system that doesn't fail in mysterious ways when people
"much more solid"???
have legitimate mail setups that happen to differ from the one the
designer anticipated. It's not unlike the advantage of DKIM over SPF.
In fact it's quite similar, but the balance is different. SPF merely requires
an administrative act to participate on the 'sending' side. This is hugely
attractive. (We'll ignore the fact that it involves the wrong address field.)
The problem is the fragility of failing to handle multiple MTA hops.
Here', we have a direct -- single 'hop' -- trust-based relationship. Much
simpler.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg