ietf-mxcomp
[Top] [All Lists]

RE: Does marid-submitter-02 really make sense?

2004-08-13 23:38:08

On Fri, 2004-08-13 at 21:30, Douglas Otis wrote:
On Fri, 2004-08-13 at 15:34, Mark Shewmaker wrote:
What tools to curtail abuse am I taking away?

By transparently redirecting outbound SMTP connections, when a client is
sending large volumes of mail not accepted because of invalid recipient
names, as example, this will appear in their SMTP logs on the provider's
machine forwarding this mail.  This is also effective in catching
Trojans that may also exist on their networks.  This is an effective
tool used to help abate abuse.

And again, how am I taking that away?

It would seem the best solution for MTA servers sharing multiple domains
would be to NOT publish any SPF or Sender-ID records.  This would
protect clients that might be harmed by repudiation services.

You want MSPs to protect their customers by effectively muzzling their
ability to publish SPF or Sender-ID records.  How paternalistic.

(If the MSP doesn't publish spf/senderID records, then their customers
have nothing to reliably redirect: to.)

Anyway, this still is unrelated to curtailing abuse, if by abuse you
mean body header forgery, and your example confuses ISP mail service
provider with non-ISP mail service providers.

I have yet to see such cautionary statements about publishing records when
clients share common servers of differing domains.

It was discussed to death on spf-discuss, generally with the conclusion
that people who are worried about this can suggest better wording on the
various wizards and documents.

I'm sure this is a problem that solves itself.  Even if howtos aren't
worded well, when people start publishing records saying others should
trust non-trustworthy MTAs, customers will start demanding more secure
MTAs.
 
Neither SPF nor Sender-ID allows an effective means to abate abuse.

Please use a less generic word that "abuse" so it's easier to understand
exactly what sort of abuse you're referring to.

It is folly to insist all mail servers will map on a one-to-one basis to
domains just to suit Sender-ID repudiations.

You are the one insisting that that is the intent.

Sorry--if my reputation system makes me give a poor reputation to
someone because they're using a shared MTA that allows cross-customer
forgeries, then my reputation system is doing it's job.

Explain that in court.

I describe my thoughts on how I figure out what I trust and don't trust,
and your response is that I'll have to explain it in court.
  
And you still don't understand why I call this a thought crime?

You claimed this identity could be submitted to a repudiation service. 
You also expect, if this allowed spam, you'd want to have that identity
blocked in the future. By not assessing the channel, instead of the
Sender-ID identity, grievous errors become possible.

It's not an error--If a domain publishes a faulty/untrustworthy
authentication record, I consider them an untrustworthy domain.

I can't imagine that in 5 years people would continue to find such
behavior as you claim as fact to be acceptable.  I expect that mail
servers that don't validate the content of outgoing email (protecting
against cross-customer forgeries among other things) will tend to cause
such mails and their purported sending domains to be rated poorly, (when
the domain gives pass results to mail from those servers.)

This is imposing a principle upon mail that does not currently exist. 
Evangelizing this scheme as some type of solution to abate abuse is
troubling, when the opposite is true.  It does not protect the RFC2822
From in many cases, most of which will remain beyond the understanding
of the mail consumer.

For one, sender_agents can solve the bit of protecting the 2822 From:.

And as for the other complaints, by definition pushing MTAs to disallow
forgeries abates abuse of those MTAs.  By definition having MTAs do
virus checks on outbound mail abates abuse.

If we weren't willing to change our expectations of what an MTA should
do, we'd still have open relays everywhere.

What should happen to mail that does not have a Sender-ID record on
these servers?

I imagine people will assign less trust mail purporting to come from
those domains, given that such mail can be easily forged.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com