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

[Douglas Otis <dotis@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx and pass with flying colors.
> 
> If someone else can spoof trustworthy@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx: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