"Mark Shewmaker" <mark(_at_)primefactor(_dot_)com> writes:
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?
This lightweight tool stops working when it must examine each message
content to find the PRA and potentially do hundreds of DNS lookups to
verify the domain. Reading mail content may even run afoul of privacy
concerns. Of course, changing these tools will require they sign a
contact with Microsoft. And what about "open" records? Should "open"
records never be used?
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.
Sender-ID removes a freedom to use a return mailbox address and requires a
contract with Microsoft. Those that refuse to accept these new
restrictions are 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.
You are confusing what is being curtailed with Sender-ID. You can not
claim all message header forgeries can be detected. Even evidence of a
verified Sender-ID identity sending a billion sexual aid remedy ads can
not be assured to have been sent by this identity. Because of the
potential for Sender-ID abuse, it could be well advised not to publish
these records.
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.
It would seem such advice should be found in the draft.
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.
We all know abuse when we see it. : )
You wish to claim Sender-ID has an ability to detect forged headers, but
even curtailing this area of abuse is over-stated. Worse, it makes
repudiation based upon this identity perilous.
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.
Either everyone publishes "closed" lists and every MTA in the path of the
mail checks for Sender-ID, or (as that checking can never be confirmed)
every domain must send from their own servers.
<snip>
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.
Again, this process of checking within the mail channel may not be in the
senders control. The repudiation service should not make this assumption
either. If there is a problem with the integrity of Sender-ID checks, who
is at fault? You wish to claim the sender is always at fault. Sender-ID
checks are done by the recipient however. As mail is often relayed, how
can the sender be held accountable for those taking advantage of security
problems later in the mail channel?
<snip>
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.
Open relays were stopped by policy enforcement. This is something that can
be tested by a third-party. The same is true for open-proxies. Saying
that an MTA must not send a virus is an evolving problem where having a
history by way of name would help with respect to the channel. Allowing
the channel to assume a few million identities, as with Sender-ID, does
not allow even a go slow 'if new' method of control.
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.
This would however allow the sender a means to avoid Sender-ID repudiation
abuse. : )
-Doug