On Thu, 2004-08-12 at 20:43, Mark Shewmaker wrote:
On Thu, 2004-08-12 at 21:38, Douglas Otis wrote:
On Thu, 2004-08-12 at 15:59, Mark Shewmaker wrote:
On Thu, 2004-08-12 at 13:09, Douglas Otis wrote:
Sure it does--use a competent mail service provider.
I do not understand why you see a network service provider monitoring
outbound mail as being incompetent.
I never said anything like that. (At least I hope I didn't.)
(Although with Unified-SPF, I would expect to look forward to a day in
which ISPs can safely remove outbound mail blocks at residential
addresses. Separate issue though.)
The method I was referring to does not block port 25, instead it
redirects the destination. Some home access providers do block port 25
out-right to curtail Trojans, but I was not referring to that.
By isolating to the Sender-ID, which may be a small percentage of the
traffic traveling through a shared MTA, even should the provider be
extremely diligent, this domain may become exploited.
Then if the shared MTA is exploited, then domain's reputation will
suffer, even if the domain didn't actually intend to be a victim.
This would be under the impression that Sender-ID could be used for
repudiations.
That's simply the way things are.
Not yet.
People will not think as highly of that PRA afterward, for some amount
of time at least, and won't put as much trust in their claims.
This leaves those harmed, but not committing a wrong, the only recourse
but to sue the repudiation service for their incompetence in considering
Sender-ID a suitable identifier for the purpose of repudiation.
People will alter their opinions. I'm sorry if that bothers you.
As a result, expect the amount of abuse to increase and repudiation
services to suffer by the onslaught of errors.
Now, if the PRA tries to start suing people who have started to think
less highly of his purported claims, then yes, I think that's unfair and
uncivilized behavior on the PRA's part.
I don't believe in thought crimes.
Blocking mail is not a thought.
It is not the same problem as checking the host by IP. The IP
properly identifies the mail stream. If there is an error that
blocks such a shared MTA by IP, the problem will be corrected
quickly. Sender-ID allows the domain to be exploited, isolated,
blocked, and ignored. Ouch.
Yeah--ouch!
I can only conclude that people who put themselves in such a vulnerable
position are likely to quickly correct the problem when their
vulnerabilities are exploited--after which their reputation should
improve.
Sender-ID puts them in a vulnerable position. Their activities were
responsible, the network providers activities were very responsible and
abuse was being abated. Now, with Sender-ID, the abuse CAN NOT be
abated. : (
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.
Or they'll go to the courts, at which point I can only hope that their
reputation would plummet. (I for one try to avoid doing business with
companies like that--companies that won't admit, stand behind, and
correct their problems.)
It will be repudiation services using Sender-ID to base their
assessments, not the network providers doing their best to abate the
abuse damaging their services.
I don't know what "transparent interception techniques" you're talking
about.
Some network providers have their routers redirect the destination
address for port 25 connections to their SMTP server to monitor the
traffic. This is a competent and effective means to quickly identify
and remove egregious abuse by checking SMTP error logs. Sender-ID could
fully validate for the wrong party however.
Oh-okay.
Well, if it could fully validate for the wrong party, then either the
MSP is allowing cross-customer forgeries, or the purported sending
domain has their SPF records set up poorly. (Or both.)
What restrictions are there with respect to PRAs currently? Providers
can't even assess the PRA without first signing a contract with
Microsoft. The SPF records must include the shared MTA, if to be set up
correctly according to both SPF and Sender-ID. This sharing may not be
apparent to the recipient.
Sender-ID does not stop phishing,
Well, sender_agents would help in the phishing area. :-)
Something like Identified Internet Mail would help. I don't know what
you mean by sender-agents. Do you mean a Certificate Authority?
It's a modifier I've been pushing for a few months as a way to get
SenderID to fully address the phishing problem, to little avail
unfortunately.
(I'm frustrated at my inability to stir up interest so far, as IMHO
sender_agents would make SenderID *FAR* more useful.)
See: http://www.imc.org/ietf-mxcomp/mail-archive/msg03112.html
<snip>
I see. Identified Internet Mail seems a much cleaner solution.
Obviously, domains whose outgoing MTA service is an MTA that allows
cross-customer forgeries will likely suffer in reputation.
Reputations based upon Sender-ID would never point to their servers as
being at fault. Here lies the rub. Sender-ID can not be trusted, and
yet the party at fault can not be identified.
Why can Sender-ID not be trusted in this context?
The identity will always be in question when over a shared MTA. The
danger is the inevitable law suit, if the wrong party is identified and
hammered by this mistake.
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. The provider guarding against abuse does not
examine or change the content of the mail, they look for protocol
generated errors. Sender-ID repudiation makes the false assumption
there is a one-to-one association of sender to mail channel in ALL
cases. Sender-ID repudiation makes the false assumption that the
identification has been accurately validated.
I simply won't think highly of people who willingly expose themselves to
such vulnerabilities. It's unfortunate if I can be prosecuted for such
a thought crime.
Blocking mail is not a thought crime.
There are multiple measures of reputation involved here--the one I
thought we were talking about here is whether you could trust claims
purportedly made by a given PRA. That's quite a different thing from
whether they're a "miscreant" by any other measure.
The PRA can not be trusted. The PRA can not be used to identify
miscreants.
The miscreant may be spoofing as
trustworthy(_at_)trustworthy(_dot_)com and pass with flying colors.
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 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.
(Ie, if trustworthy is a friend of mine who I happen to trust 100%, and
he trusts a specific IP 100%, but I only trust it 10%, then I should
only trust messages from through that IP, where I can only authenticate
via that IP, by just 10%. Goofy wording, but you get the idea.)
Either mail gets accepted or rejected. There tends to be a binary
relationship with this decision, but the integrity of the system ensures
the sender knows of this. If you filter mail into folders, then there
will be mail stuck into rat-hole folders where your friend wonders why
you did not see their message.
If you wish to have a basis for repudiation, start with an identity that
can better trusted. How about
trustworthy(_at_)trustworthy(_dot_)com:mx01.really-big-isp.com where the
authenticated EHLO domain becomes part of the identity. To process this,
mask the sub-domain of the EHLO response.
That makes sense, except for the EHLO bit, (getting people to give
honest EHLO strings is going to be another herculean effort, GRRR),
but..the real reason I wasn't pushing for that level of things is that I
don't expect people who report problems to, on the whole, be able to
reliably report the sending EHLO domain or even IP.
That was the concept behind CSV. The incentive would be name based
accreditation that helps avoid these filter rat-holes. It would not
step upon the isolated domain, nor depend upon everyone giving up their
preferred email address when obtaining access from differing locations.
It should prove more reliable than a PRA, especially when there are a
few dozen headers that may contain such information, but only a single
EHLO domain. It does not require a Microsoft contract, and it does
allow a safe means of repudiation or accreditation.
Plus--I expect that people will move to more trustworthy MSP's that
don't allow cross-customer-forgeries, so I'm guessing that that level of
resolution will not only become unnecessary, but end up being too much
work for people to be willing to bother with.
It seems Sender-ID reduces the choices but then ignores policies of the
providers where a reduction in abuse can be made. This will increase
the amount of abuse. This will force people into using an increased
number of email addresses and make a recipient less able to discern
someone they trust from a con. By exposing an authenticated EHLO
domain, the con is thwarted without forcing everyone to change their
email address to send mail. It is also an identifier that can be safely
assessed.
You are suggesting it is okay to block those that might share an MTA
server?
If it's an insecure MTA, yes: Today I block MTA IPs that are known to
be compromised and spewing viruses. There may be trustworthy people
using those IPS--too bad. :-/
But I don't see any reason to block mail from a shared MTA that doesn't
allow cross-customer forgeries.
Unless they sign a contract with Microsoft, the provider can not assess
the identity you wish to protect. Many individuals prefer that this
message information not be examined by the mail channel.
But one that does allow those forgeries, and for whom that's become a
practical problem, yeah, I would tend to start wanting to block other
domains using that MTA. (From a practical point of view it's not a
binary thing--some folks would allow a bit and then notice and correct
the problem, and for other's it's a technical possibility but a
practical impossibility to any large extent.)
Should there be a list of shared MTAs? Would that be used by some to
block mail? Would that result in law suits? It seems this is the
question.
It seems your only defense would be to always use a single recipient
limit if you refuse to merge a per user white-list. If the cost for that
feature is enough, you should be able to detect abuse by way of logs to
make this method of attack rare.
Yeah.
And to be fair, if most MTA's switch to using SUBMITTER anyway, then
it's mostly only the forgeries that become expensive. And I guess it's
probably worth the expense there.
As I said, BATV ends this without a large adoption.
No it doesn't.
BATV and SES only help for domains in which the purported sending domain
participates.
If the bounce recipient is eager to see this traffic stop, BATV would be
easier than blacklisting legitimate providers that send bounces and then
cause themselves worse problems.
As I said, it seems your only defense would be to always use a single
recipient limit, if you refuse to merge a per user white-list. It would
be foolish to expect cooperation if this were an attack.
Correct.
A receiving MTA that didn't want to check could always just prepend the
SUBMITTER in a Resent-From body header, and then MUAs would be able to
see what was verified.
I suspect this will be the standard practice used by all providers.
Prepend a Resent-From to quell support calls. Is this a good practice?
It's a lazy way for recipient MTAs to operate, against the spec but
somewhat compatible with it as far as end results go, but I hope they
won't *actually* do this.
The shortest path would be to stop at the EHLO domain and ask if the
From is part of that set.
I don't see how that would help--the server sending the message can be
different from the domain listed in the return path.
A name list of the EHLO domains would be a more concise means to make
channel assertions about the RFC 2822 From. (The list residing in From
DNS.) This should be used as an exception and hopefully, things like
Identified Internet Mail would make this choice seem lame. For
institutions wishing to protect their trust relationships, then the From
and not PRA protection is desired. Not allowing even a forwarded
message would seem reasonable for this exceptional case. BATV with a
public key may allow an exception for this limitation however.
-Doug