On Fri, 2004-08-13 at 15:34, Mark Shewmaker wrote:
On Fri, 2004-08-13 at 13:57, Douglas Otis wrote:
On Thu, 2004-08-12 at 20:43, Mark Shewmaker wrote:
Or they'll go out of business.
There is a high cost for spam where much of this is seen by the network
provider. Taking away tools to curtail this abuse is not a good
solution and can drive providers out of business.
What tools to curtail abuse am I taking away?
If a business loses money because their customers realize that they
can't trust that mail claiming to be most recently (re)sent into the
mail by them really was, then whether that distrust built up because
they didn't publish spf records or whether it built up because people
realized that the spf records they did publish could not be
trusted--either way their customers will leave.
How is that taking away tools to curtail abuse?
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.
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. I have
yet to see such cautionary statements about publishing records when
clients share common servers of differing domains.
Although SPF could help reduce some of the spoof address bounces,
Sender-ID will not. Neither SPF nor Sender-ID allows an effective means
to abate abuse. Transparent redirection of the SMTP protocol does this
effectively however. If the trade-off is for less spam or fewer options
of which email address someone may use, I'll opt for less spam. It is
folly to insist all mail servers will map on a one-to-one basis to
domains just to suit Sender-ID repudiations.
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.
The provider guarding against abuse does not
examine or change the content of the mail, they look for protocol
generated errors.
Well, I for one won't trust mail from mail servers run with such a
mindset as compared with mail from mail servers that have what is in my
opinion a more enlightened mindset.
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. The promise of checking these identities is also
troubling with these many cases where such checks are meaningless, but
never clarified.
Although promoters of the Sender-ID scheme are savvy about the inability
of this to curtail spam, this feature is always suggested to be the next
step. The fact that this scheme does not provide a foundation for this
next step is important, as most expect spam abatement was the initial
motivation. Asking people to abandon methods that control spam while
not allowing an alternative seems irresponsible.
If someone else can spoof trustworthy(_at_)trustworthy(_dot_)com, then I
hope my
reputation systems will assign a poor reputation to the trustworthy.com
domain, because any claims of anyone to be from there aren't, well,
trustworthy.
The question should be, do you blame the mail system allowing mail to
share MTA servers as designed, or do you blame repudiation services for
not considering such cases.
The problem is that trustworthy.com told me I could trust an untrustable
MTA.
Trustworthy.com could go to a more trustworthy MSP, or they could try to
convince their MSP to disallow cross-customer forgeries.
It seems folly to trust the RFC2822 headers without some stronger means
of ensuring such assertions. SMTP does not offer a means to evaluate
the security of the channel, nor does Sender-ID. Sender-ID makes
fundamentally invalid assumptions such headers can be trusted. It would
be better to authenticate the mail channel and added this identity to
that of the RFC2822 From. This would provide far more clarity as to what
is being trusted. You are not trusting the domain that originates the
mail, you are trusting the last link in the chain providing the mail.
Sender-ID seems willing to ignore this reality, and allow false
assumptions about what can and cannot be checked. There can be special
cases where such could be better assured, but this can not be generally
applied, as Sender-ID suggests.
The fact that trustworthy(_at_)trustworthy(_dot_)com tells me to trust that
a
message really comes from him if it comes through a specific IP still
doesn't mean I should trust such claims if I know that that specific IP
itself isn't trustworthy.
Mail providers MUST NOT use Sender-ID when they can not ensure a
ONE-TO-ONE relationship between Domain and Server. The draft should
make this warning very clear, but it does not.
I see no problem with a zillion domains having a single server as an
outbound MTA if that single server doesn't allow cross-customer
forgeries.
You make this sound easy. This would not be one Sender-ID record per
client, it would be a Sender-ID per message that must be read. It may
take as much as 200 seconds to process per spec. At 10 seconds per
message, that could increase equipment cost as much as 20 fold. The 20
second limit per record may put those in Europe and Asia at risk when on
a different continent. Sender-ID records must always be closed for such
protection, but open lists are allowed.
What should happen to mail that does not have a Sender-ID record on
these servers? Forgery protection then demands RFC2822 headers be
examined and processed for the PRA, if there are records. This means
every provider much sign a contract with Microsoft for this to happen.
I saw nothing where terms of this contract will not change. It does
prevent transfer of this contract however, which could be a problem when
the service changes hands.
Most MUAs allow setting the MAIL FROM parameter. Why not use that? If
those phishing or spoofing use a Resent-From header, it is no worse than
using the MAIL FROM. Always make the EHLO domain and MAIL FROM
visible. At least this does reduce the spoof mail bounce problem and
ensures everyone is checking the same parameter. It will also make
spoofed mail stand out like a sore thumb with or without Sender-ID or
SPF records.
-Doug