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

From: "Harry Katz" <[email-masked]>
Date: Mon, 9 Aug 2004 17:56:14 -0700

On Monday, August 09, 2004 4:49 PM Shevek wrote:

> On Mon, 9 Aug 2004, Harry Katz wrote:
> 
> > On Monday, August 09, 2004 10:24 AM [email-masked] wrote:
> > 
> > > First, I am not proposing anything here. Not only is 
> SUBMITTER not 
> > > my idea, I have been quite clear that I am ambivalent about its 
> > > inclusion in MARID.
> > > 
> > > Second, the optimization in case 1 isn't a failure case but a 
> > > success case.
> > > There may be a throughput improvement in some MTAs if the 
> check can 
> > > be done sooner. Mind you, I'm not saying there is 
> guaranteed to be 
> > > such an improvement
> > > - just that it is a possibility. Actual implementation experience 
> > > would be needed to tell for sure.
> > 
> > Ned is exactly correct here.  The purpose of SUBMITTER is to allow 
> > early (i.e. at 2821-time) verification of the sender's identity, 
> > namely the PRA.  At the IETF meetings last week there was some 
> > discussion of whether this would result in bandwidth saving, 
> > throughput improvement, or no benefit at all.  I tend to 
> think there 
> > will be modest throughput improvement, but agree with Ned 
> that we need to verify through testing.
> 
> This is incorrect. At 2821 time, we know only who the sender 
> CLAIMS to be via SUBMITTER. It's not until after 2822 time, 
> when we can compare the SUBMITTER value to the PRA value 
> computed from the 2822 headers that we have verified the 
> identity of the sender.

Actually, it is correct.  From section 4.2 of the submitter-02 draft:

   If these tests indicate that the connecting SMTP client is not
   authorized to transmit e-mail messages on behalf of the SUBMITTER
   domain, the receiving SMTP server SHOULD reject the message and when
   rejecting MUST use "550 5.7.1 Submitter not allowed."

   If the receiving SMTP server allows the connecting SMTP client to
   transmit message data, then the server SHOULD determine the purported
   responsible address of the message by examining the RFC 2822 message
   headers as described in [SENDER-ID].  If this purported responsible
   address does not match the address appearing in the SUBMITTER
   parameter, the receiving SMTP server SHOULD reject the message and
   when rejecting MUST use "550 5.7.1 Submitter does not match header."

In other words, if SUBMITTER is present and fails the Sender ID check at
2821 time, then the message SHOULD be rejected.  The subsequent matching
of SUBMITTER to 2822 headers is only to confirm - if DATA is accepted -
that the SMTP client didn't lie about the value.

---

From: Shevek <[email-masked]>
Date: Tue, 10 Aug 2004 11:02:01 +0100 (BST)

On Mon, 9 Aug 2004, Harry Katz wrote:

> > > > First, I am not proposing anything here. Not only is SUBMITTER not
> > > > success case. There may be a throughput improvement in some MTAs
> > > > if the check can be done sooner. Mind you, I'm not saying there is
> > > > guaranteed to be such an improvement - just that it is a
> > > > possibility. Actual implementation experience would be needed to
> > > > tell for sure.
> > > 
> > > throughput improvement, or no benefit at all.  I tend to think there
> > > will be modest throughput improvement, but agree with Ned that we
> > > need to verify through testing.
> > 
> > This is incorrect. At 2821 time, we know only who the sender CLAIMS to
> > be via SUBMITTER. It's not until after 2822 time, when we can compare
> > the SUBMITTER value to the PRA value computed from the 2822 headers
> > that we have verified the identity of the sender.
> 

This is NOT equivalent to a verification of the sender's identity, as 
suggested above, and therefore does not permit an early success 
optimisation. There is no shortcut.[0]

It does permit early failure, but if implemented correctly, one would hope 
that the spammers would be forced to use the success case. Thus this 
optimisation offers no saving of bandwidth, CPU or anything else.

S.

[0] I fully expect many implementations to implement this as a shortcut, 
and weaken the system. The later processing is too complex and breaks the 
layers which so many MTAs are architected to respect.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/

---

From: Mark Shewmaker <[email-masked]>
Date: Tue, 10 Aug 2004 08:42:21 -0400

> optimisation offers no saving of bandwidth, CPU or anything else.

Nah, there are some minor, meager optimizations.

And there is a super-duper, super-serious, point-blank, shockingly huge
optimization.

First the boring, minor optimizations:
--------------------------------------

The existence of a SUBMITTER in the MAIL command could provide meager
throughput optimizations, even in the success cases:

1.  If the receiving MTA is doing SenderID tests and no SPF-Classic
    tests:

    Then the receiving MTA could immediately start doing DNS
    queries and Sender-ID tests at MAIL time, even if it doesn't
    act on the results until after DATA.

    So instead of taking N network-limited milliseconds to do the
    Sender-ID test after data, tacking N to the length of time
    otherwise needed to process the hole message, it could do that
    N milliseconds worth of work/waiting in parallel.
    
2.  If the receiving MTA is doing SenderID tests *and* Classic SPF
    tests:

    Then there's going to be a short delay at MAIL FROM *anyway* just
    to do the classic SPF tests.

    I'm *guessing* the classic SPF tests would take about the same
    amount of time as the Sender ID tests, so why not just do them
    in parallel?

3.  Any other not-directly-SenderID test based on SUBMITTER could
    be substituted in (1) or (2) above, such as domain-based reputation
    tests.

    (Or full-email-address (!!!) based reputation tests.)

However, since these are merely optimizations, and probably not overly
noticable ones at that, I wasn't big on any requirement to use
Submitter.  (At one point way back when there were flag days and the
like where you'd be required to use Submitter.)

The shockingly huge optimization:
---------------------------------

***HOWEVER***, there is one serious advantage to using SUBMITTER that I
had completely forgotten about:

           Per-Recipient Rejects.

Imagine that one recipient has white-listed a given PRA, and a second
recipient hasn't--and so there's a situation where an incoming message
should be sent to only the first recipient and not the second.

Here are three possibilities for that situation for a receiving MTA:

If you're given SUBMITTER:

  Possibility 1:   Accept the first RCPT TO:
                   Reject the second RCPT TO: with 5.7.1
                   Accept DATA.

If you're not given SUBMITTER:

  Possibility 2:  Accept the first RCPT TO:
                  Accept the second RCPT TO:  
                  Accept DATA.
                  Run SenderID tests.
                  Find the second RCPT TO: fails SenderID tests.
                  BOUNCE the second RCPT TO with 5.7.1

                  This choice means you're running the risk of being
                  a source of forged bounces if you didn't also do 
                  Classic SPF tests.  Oops.

  Possibility 3:  Accept the first RCPT TO:
                  Reject any subsequent RCPT TO:  "too many recipients"
                  Accept DATA.

                  You soon get another connection from the same MTA.
                  Reject the first RCPT TO: with 5.7.1 (which was
                                                        recipient #2 
                                                        earlier)

                  You're supposed to always be able to accept 100 
                  recipients, but if you always max out at one
                  when you don't have SUBMITTER, then you can safely
                  do per-recipient rejects that way, without bouncing.

So, here SUBMITTER is a *serious* optimization!

So if you allow recipient white-listing, you either have to either:

1.  Max out at just one recipient, and get 100 separate connections for
    100 separate attempted recipients,

    OR

2.  Run SPF Classic tests on MAIL FROM, and *bounce* messages failing
    SenderID tests.

Either way, your bandwidth is sucked away like crazy.

But wait--it's worse!!

What if you chose option (2), running SPF classic and doing SenderID
tests--you *still* can't safely bounce unless you get an SPF pass
result!

That means that if you're running SenderID tests with recipient
white-listing (and hopefully with sender_agents, plug-plug), and your
MTA gets a connection without SUBMITTER, the only safe way to proceed is
to:

   Run SPF Classic tests on MAIL FROM:

   If result==PASS:
      Accept as many recipients as you like.
      Bounce messages failing SenderID tests.
   else:
      Accept only ONE recipient maximum.
      be prepared for multiple reconnects.

(Anyone want to suggest an SMTP extension for after-data per-recipient
rejects?)

If you're given SUBMITTER, you can do per-recipient rejects safely, of
course.  But folks who want to trick you into sending their bounce spam
won't be all nice and give you a cool SUBMITTER to play with--and
without SUBMITTER you have this yucky issue.

(Side note:  If you do get SUBMITTER and SUBMITTER!=PRA, then it's safe
to reject after DATA for *all* recipients, because this is clearly
either a corrupt or forged mail transmission.)

-- 
Mark Shewmaker
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Aug 2004 11:34:55 -0700

> First the boring, minor optimizations:

The Mailbox Domain identified by Submitter can not be used for
reputation checks!  This Mailbox Domain does not indicate the origin of
the message, being the entity granting access to the mail stream.  There
would be little upon which to base repudiations and thus little gained
from such check.  Using this Submitter Mailbox Domain repudiation would
expose the many opportunities for Sender-ID spoofing that still exist,
and harm those left vulnerable by many shared MTA channels. 

> The shockingly huge optimization:

Neither Sender-ID nor Submitter stop bounces as there are no checks
against the MAIL FROM.  As mail, at many nodes, operates using a store
and forward mechanism, there will always be ample opportunity to create
a bounce.  This example is applying a per recipient white-list at the
initial MTA receiver.  This assumes all MTAs have been provided these
per-recipient white-lists.  This assumption is flawed as there will be
configurations where this does not apply and spammers are expert at
finding them.

>                     do per-recipient rejects that way, without bouncing.

The white-listing could be based upon the MAIL FROM without using
Submitter.  If the PRA is not the RFC 2822 From, what would Submitter
white-listing accomplish?  Would this be greatly different from the use
of MAIL FROM?  A reaction by large ISPs to the use of Sender-ID could be
to then include a Resent-From header to allow customers an ability to
continue their normal practices. (Saving them a fortune is their support
center.)  In such a case, MAIL FROM is still as good, if not better than
Submitter.  

> So, here SUBMITTER is a *serious* optimization!

This is ignoring the likely outcome of this mechanism and the defensive
strategy likely to result.

> 2.  Run SPF Classic tests on MAIL FROM, and *bounce* messages failing

I assume you mean Reject messages failing Sender-ID checks.

> Either way, your bandwidth is sucked away like crazy.

This ignores the required 10 host_checks() functions calls.  Assume each
TXT record references 8 MX records which then requires 5 A record
lookups, as in the example by John Levine.  That would be 400 DNS
lookups resulting in about 1.3 queries per lookup (520) to arrive at the
400 answers.  If each query resulted in a normal mean of about 100 ms,
that would be 52 seconds, well within the 200 seconds alloted by the
draft.  If at about 400 bytes per record (counting both directions), the
resulting traffic could be over 200 kbytes of UDP traffic, for about 8
kbytes of an average message.  Spam is even smaller at about 4 kbytes. 
If the DNS cache hit rate is 80%, assuming the cache can withstand the
added amount of Sender-ID records, the traffic is still 40 kbytes. 
Spammers however often employ a wildcard record and random sub-domains,
making caching ineffective.  Bandwidth can definitely be a concern, but
Submitter does not offer a solution for this.    

> (Anyone want to suggest an SMTP extension for after-data per-recipient

It seems refusing to accept multiple recipients, as you indicated, on a
normal basis would arrive at the same result.  This would work with or
without Submitter, when applying per recipient white-lists at the MTA. 
This could be seen as a means to avoid bounces at all costs, to bolster
Sender-ID that does not check MAIL FROM. 

> without SUBMITTER you have this yucky issue.

It seems you have concluded Submitter is not an optimization after all. 
This problem of multiple recipients is only when they share the same
receiving MX server as well.  

> either a corrupt or forged mail transmission.)

That assumes there is a check made at this point.  This is the great
downside when allowing Submitter.  This check becomes optional and the
modicum of security goes out the window.

-Doug

---

From: Mark Shewmaker <[email-masked]>
Date: Wed, 11 Aug 2004 02:04:41 -0400

On Tue, 2004-08-10 at 14:34, Douglas Otis wrote:
> reputation checks!

Sure you can--you can see if you have white-listed that PRA yourself, or
if your trusted friends have--thus giving you reason to believe claims
made by this PRA,

Or you could filter out PRAs with bad reputations--those appearing on
domain-based block lists.

This isn't as useful as a sender_agents based end-to-end trust chain,
but then again, I did put this "optimization" under the "boring, minor"
heading.

> configurations where this does not apply and spammers are expert at

The problem comes with configurations with per-recipient controls.

That's the case I'm worried about.

If you're doing per-recipient white-lists, and you don't have SUBMITTER
but you want to do SenderID PRA checks anyway, you have to check after
DATA.

But since you can't reject per-recipient after data, you have to bounce
after data instead.

But you can't safely bounce after data unless you've had an classic SPF
PASS result.

And that's a opportunity for spammers to have you send out forged
bounces, if you've put yourself into a position to have to send out
potentially forged bounces or throw away accepted mail.

> strategy likely to result.

I meant it a bit tongue-in-cheek.

If you do get SUBMITTER, then you don't have to worry about being used
to generate bounce spam, since you can do per-recipient rejects. 
(Obviously, there's a problem if another machine of yours has just
relayed the message to you--so your rejecting the message would cause it
to bounce the message--but that's a separate vulnerability in your
setup.)

And so you don't have to do all this extra work to counter possible
bounce forgery attempts directed at you.  Hence, "optimization."

> I assume you mean Reject messages failing Sender-ID checks.

No, I actually mean "bounce."

If you are sent a message without SUBMITTER, you have to do SenderID
tests after data.

But if one recipient's policies has you accepting that message and the
other has you not accepting it--after DATA you can't reject per-user, so
you have to bounce instead.

But you're stuck if you can't safely bounce if you don't have a full SPF
PASS.

> kbytes of an average message.

But at worst all these queries should be locally cached by the time you
get to the first RCPT TO: value.

So if your test code doesn't cache data itself, you're just querying dns
records cached on your own machine, or on a machine very close to you.

And two of the spf test libraries actually do caching internal to the
libraries.

I'm not very worried about DNS bandwidth.

> Sender-ID that does not check MAIL FROM. 

Yeah.   I'm wondering if, were any RFC to come out for an smtp extension
allowing per-recipient after-data rejects, if it would soon become
acceptable to give "too many recipient" errors on second and subsequent
recipients when the sending MTA (!) doesn't support such an extension.

> receiving MX server as well.

It is a meager optimization for the single-recipient case, but in the
multiple-recipient case, it's an "optimization" in that it allows you to
avoid wasting bandwidth that's necessary to waste if you want to avoid
the security issues inherent in doing per-recipient after-data checks.

> modicum of security goes out the window.

Without sender_agents, which has end-to-end tests, I don't see why it's
so bad if some implementations skip the required SUBMITTER==PRA test,
because if you got a message with SUBMITTER!=PRA where the SUBMITTER
value would have caused you to accept it if it were equal to the PRA,
then the sending machine could have just added a "Resent-From:" at the
top of the body headers to have had it pass that SUBMITTER==PRA check.

I don't see how the fact that it didn't bother to fill in some paperwork
mean that there's a security check.

(Now, if Resent-From: included some cryptographic checksum of the rest
of the message, that would be a different story--but it doesn't.)

-- 
Mark Shewmaker
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2004 10:03:41 -0700

> if your trusted friends have--thus giving you reason to believe claims

A public list assessing these identities used to block mail would be
doomed.  Abuse *beyond* the domain holder's control would elicit a legal
challenge to any assertion of their reputation that stops their mail. 
There would be no other recourse.  There may be hundreds of such domains
sharing a transparent MTA imposed by their ISP.  This convergence may
not be apparent to the recipient, but would allow any of these hundreds
of domains to assert any of these Mailbox Domains.  Also, how would you
rate Mailbox Domains that resolve to being valid, but are outside their
prescribed Mail Channel?  And of course, the Mail Channel is not secure,
so any conclusions based upon this indirect assertion of content *must*
be dismissed.  This would be trusting a third-party MTA without an
opportunity to examine the related integrity of the Mail Channel.

> domain-based block lists.

A provider of these services would need to obtain a contract that
stipulates PRA identities will NOT be used in conjunction with their
listing services.

> but then again, I did put this "optimization" under the "boring, minor"

I would put it under wishful.

> potentially forged bounces or throw away accepted mail.

If using a per recipient white-list, if accepting multiple recipients in
one mode but not the other, if subsequent recipients fail to white-list
this sender, if this has not been internally forwarded, then there will
be a bounce.  As one of your users have vouched for this sender, a
bounce should not be a problem, as this is not a bad actor.  Merging all
recipient white-lists would allow logical treatment without Submitter
and would avoid the onerous single recipient mode.

> to bounce the message--but that's a separate vulnerability in your

Merge your white-lists.  If any use vouch for the sender, then they are
not likely a spammer.  This avoids the one recipient mode.  Hence,
"optimization" without Submitter.

> you have to bounce instead.

You did not qualify this.  But again, I think this can be easily avoided
by consolidating white-lists in a first pass check.

> But you're stuck if you can't safely bounce if you don't have a full SPF

That may flag a problem with one of your users white-lists.

> get to the first RCPT TO: value.

After 52 seconds?  Roughly 5% of these will likely be lost and I stated
that 80% were cache hits (assuming normal mail).  That could mean out of
the 104 queries, about 5 will time-out.  So 52 seconds goes to 77
seconds with nothing unusual or out of the ordinary.  Of course, if this
were a spammer, then don't except a high cache hit rate as they tend to
use random sub-domains with wildcard records.   Sorry, but this
information in either case is not cached so quickly.    

> records cached on your own machine, or on a machine very close to you.

At some point, these queries will become present on the WAN.  DNS
caching is not 100%.  There are things like TTL and I would expect
overflow conditions being dealt with due to the abhorrently high traffic
generated by the Sender-ID bloat.  Should the records indicate ?all, and
using an access point outside of the prescribed Mail Channel, then each
an every record must be checked. : (

> I'm not very worried about DNS bandwidth.

Obviously.

> recipients when the sending MTA (!) doesn't support such an extension.

Would the sender enumerate each recipient in some fashion to then allow
selective rejections? 

> the security issues inherent in doing per-recipient after-data checks.

This assumes a list of other conditions that go with this rather limited
case.  Again, merge the white-lists to create a general case.  This
should lessen much of your concerns.

> of the message, that would be a different story--but it doesn't.)

The problem you seem to overlook is that the MUA does not see
Submitter.  If this goes unchecked, then what is the user seeing and has
Submitter helped?  In this case, Submitter defeats the intended value
and only adds complexity.  As submitter is not seen in the message, it
would also create problems trying to resolve different PRA resolutions. 
This seems to be an expensive feature with respect to support centers
and it lowers security.

-Doug

---

From: Mark Shewmaker <[email-masked]>
Date: Thu, 12 Aug 2004 07:39:25 -0400

> challenge to any assertion of their reputation that stops their mail.

Then people who live in jurisdictions where such is possible will
suffer, but that's no reason to make those who live in more civilized
parts of the world suffer along with them.

> of domains to assert any of these Mailbox Domains.

Obviously, domains whose outgoing MTA service is an MTA that allows
cross-customer forgeries will likely suffer in reputation.

That's quite as it should be, IMHO.

If honest-company.com authorizes incompetent-isp.com to send mail on
their behalf, but incompetent-isp.com lets we-love-to-forge-emails.com 
use their servers to forge emails in honest-company's name, well of
course honest-company's reputation will suffer.

That will happen now, just more indirectly, via IP-based block lists. 
It can happen after SenderID becomes popular, (assuming people do
classicSPF tests to of course), via domain-based (and email based?)
block lists, for domains whose outgoing smtp services are hosted at ISPs
allowing cross-customer forgeries.

But it won't be such a concern for ISPs and other mail service providers
that don't allow cross-customer forwarding.  So things are only
improving in that way.

> Also, how would you
> prescribed Mail Channel?

I don't understand what you're trying to ask.  I don't quite understand
the sentence.

> stipulates PRA identities will NOT be used in conjunction with their

Why?

> As one of your users have vouched for this sender, a
> bounce should not be a problem, as this is not a bad actor.

I wouldn't assume the "not a bad actor" bit--we're talking about
potential attack vectors, so by definition we have to assume that anyone
could be a bad actor.

Imagine I were an ISP and a forger wanted to use my machine as a source
of bounce spams.

He could sign up an account "forger" on my machine, then from elsewhere
send the bounce spam to his new account and to another customer of
mine.  As he white-lists himself, his own mail won't bounce because it's
sent to his account, (and he presumably forwards it somewhere else to be
sent to /dev/null there), but it does bounce when sent to the innocent
subscriber--and thus it gets bounced to the "victim" account.

Now the "victim" could be one of a number of targeted accounts--or it
could be one of a number of people known to immediately become incised
at bounce forgeries, such that that they quickly get my IPs put onto
blocklists before I realize what's going on.

> Would the sender enumerate each recipient in some fashion to then allow

"selective rejections"--I like that.

Possibly--for such an extension to work, the SMTP client would have to
let the server know that it understood the extension too, one way or
another.

Perhaps if, after the server said it supported selective rejectsions
after data, say by putting "SRAD" in the EHLO response, the client could
enable that behavior with a new "SRAD" command by itself, or perhaps
putting "SRAD" as argument to each and every RCPT command.  (Though the
later seems wasteful to me.)

I'm sure there's lots of ways this could be done--and it's by far a more
straightforward problem that SenderID.

Interestingly enough even if solving this problem were in-scope for this
group, so that the same RFC that published SUBMITTER also publishes an
after-data-selective-rejections extension, that's *almost* a no-op for
SenderID purposes. (!)

Clients and servers that supported SUBMITER would have no need for the
other extensino because of SenderID purposes, (though it would be
convenient for other types of recipient-settable after-data tests),
because they'd be using SUBMITTER anyway and thus allowing for
per-recipient *pre*-data rejects, which is what everyone wants in the
first place.  (Well, everyone but forgers and the like.)

So, I'm guessing that if NO SUBMITTER == Pull-PRA-from-headers, that
smtp servers will simply have to allow only one recipient per
no-SUBMITTER message at some point.  (Or perhaps more than one--up to
the first recipient with a different white list.)

Not fun.

> The problem you seem to overlook is that the MUA does not see

If the standard allowed the sending MTA to just make up a SUBMITTER
without it being in the headers, the presumably it would also be changed
to allow the receiving MTA to add non-PRA SUBMITTERS to the headers as a
PRA.  So IMHO, this specific security worry is more of a moot point--the
standard could be worded either way really.

-- 
Mark Shewmaker
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Aug 2004 10:09:07 -0700

> parts of the world suffer along with them.

This does not provided the domain holder any alternative!  They have
done nothing wrong, and yet a listing based upon Sender-ID claims they
did.  As a result, their mail is stopped.  What is fair or civilized
about that?  These transparent interception techniques ARE civilized and
DO provide significant relief from the amount of abuse suffered upon the
world.

Sender-ID does NOT offer even a modicum of relief from spam nor enable
enforcement.  The advocates of Sender-ID exclaim "It is not about
spam!"  (This is coming from a group tasked to carry forward work of the
ASRG?)  This is a puzzle.  Sender-ID is not about accurately identifying
the sender either.  Sender-ID does not stop phishing, spoofing or
curtailing spoof bounces.  The discernible purpose is to disable outside
mail services, or, as claimed by Microsoft at the Open Group Forum,
Sender-ID is to increase the number of Outlook folders.  : (   

> 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.

> That's quite as it should be, IMHO.

If you were not wishing to take any action against spam, perhaps.

> course honest-company's reputation will suffer.

Based upon which reputation service?  These providers will spend their
scant time in court, if they were foolish enough to depend upon the
ability of Sender-ID identify miscreants.  

> That will happen now, just more indirectly, via IP-based block lists.

So you are advocating IP based blacklisting as the solution?  
 
> allowing cross-customer forgeries.

This sounds like mumble, hand-wave.  Are you advocating to block all ISP
that take measures to control spam, in favor of this new goal of
restricting the use of RFC2822 From Mailbox Domains?  

> that don't allow cross-customer forwarding.  So things are only

You mean to enable spammers?

> > Also, how would you rate Mailbox Domains that resolve to being
> > valid, but are outside their prescribed Mail Channel?
> 

Sender-ID allows 5 or 6 levels of acceptance.  Sender-ID may validate
mail as being fully rated without having emerged from a prescribed set
of MTA clients.  How does this mail get classified?  Would you suggest
anyone using one of the Sender-ID options should have their mail
blocked?  The contract provided by Microsoft specifically absolves them
from this type of harm.  Who will find themselves in court then?

> > stipulates PRA identities will NOT be used in conjunction with their

Sender-ID must not be trusted as explained.  Expectations of a
reputation service used against the PRA will not provide satisfactory
results.  In addition, complaints raised as a result must be ignored. 
If to provide a reputation service, it must be made clear PRA is not a
valid basis for registering complaints nor blocking spam.  Is there a
better way to make that point clear?

> potential attack vectors, so by definition we have to assume that anyone

You have allowed a user to create a white-list.  If you discover they
are white-listing an egregious spammer sending in bulk to non-existent
users in your domain, you may reconsider allowing this specific
white-listing or perhaps dropping this user.  If these messages are to
valid users, then it does not sound like a typical spoof bounce attack. 
It also appears they do not appear on an IP blacklist. 

> subscriber--and thus it gets bounced to the "victim" account.

I assume you are suggesting this spammer also knows valid accounts on
your system, but also knows that these other users will be rejecting
their message based upon a filtering result (not a blacklist).

> blocklists before I realize what's going on.

Hence the need for BATV?  As you said, this spammer may not cooperate by
using Submitter either.  Submitter does not seem to offer any
"optimizations" nor does Sender-ID even inspect MAIL FROM.  

> later seems wasteful to me.)

Fine. 

> the first recipient with a different white list.)

Hence BATV?

> standard could be worded either way really.

The standard can not enforce what a miscreant does.  The danger, as
stated, is that if only submitter were checked, it would not matter what
was contained within these headers and the user would be under the false
impression at least one of the headers had been checked.  What had been
checked will remain a mystery.

-Doug

---

From: Mark Shewmaker <[email-masked]>
Date: Thu, 12 Aug 2004 18:59:41 -0400

On Thu, 2004-08-12 at 13:09, Douglas Otis wrote:
> This does not provided the domain holder any alternative!

Sure it does--use a competent mail service provider.

> They have
> about that?

It's perfectly fair and civilized.

If you purchase outbound SMTP service from an incompetent mail service
provider, their incompetence will mean that you can appear to be
engaging in activities that you're not intending to engage in, and
recipients will not have any reliable way of telling the difference
between your activities and your MSP's actions.

That will affect your reputation, no question about it .(Think of the
old AEGIS (sp?) IP-based blacklistings a few years ago.)

You always have a recourse of going to a better mail service provider.

> These transparent interception techniques ARE civilized and

I don't know what "transparent interception techniques" you're talking
about.

> Sender-ID does not stop phishing, 

Well, sender_agents would help in the phishing area.  :-)

> yet the party at fault can not be identified.

Why can Sender-ID not be trusted in this context?

Yes, I agree that it "cannot be trusted" to solve the entire set of
problems that it was purported to solve, as well as the problems point
out that it won't solve, but it can still identify PRAs--and so if you
have a reputation system that you can query about PRAs you've
identified, that reputation system could tell you whether you can trust
claims from those PRAs.

In the case of an untrustworthy PRA, I wouldn't care very much which
particular server that message came from, if claims purportedly made
from that PRA were said to be untrustable.

> If you were not wishing to take any action against spam, perhaps.

I don't care to take any direct action against spam, no.  (Direct action
being things like initiating lawsuits, or even spending hours on the
phone trying to get network providers to cut off accounts.)

I just want systems that authenticates senders in multiple ways, and
other systems that provide various measures of reputation against
senders, with an end result that recipients by and large aren't affected
by the onslaught of spam attempting to reach them.

Taking direct actions against spam is a lot more work, and I'm lazy. 

I'd rather everyone be able to avoid the problem, let forgers and
spammers slowly find it harder and harder to acquire new victims, and
let them move to more lucrative (and hopefully more honest) pursuits.

> Based upon which reputation service?  These providers will spend their
                                        ^^^^^^^^^^^^^^^
Who do you refer to here?

> ability of Sender-ID identify miscreants.  

Spending their scant time in court?  Talk about unfair and uncivilized! 
:-)
 
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.

One can only hope for the development of a distributed reputation system
into which reporting participants could securely
anonymously/pseudonymously enter information.  I only hope it's
mathematically possible to do some sort of (buzzword alert) combination
of zero-knowledge proof and automatically-maintained webs of trust
between pseudonyms, (separate writing-versus-reading webs too
hopefully.)

> So you are advocating IP based blacklisting as the solution?  

It's the substandard solution available now.
 
> restricting the use of RFC2822 From Mailbox Domains?

You're not making sense.  Where do you get this "block all ISP" bit?

I just expect that people who use ISP/MSP's that allow cross-customer
forgeries will end up with worse reputations than if they went to more
competent ISP/MSPs.

> better way to make that point clear?

I don't know, but it still doesn't make sense to me.

Let's say that you use a reputation system says that the PRA
"[email-masked] is not trustable.

Then even if you get a SenderID PASS on that PRA, unless you've
overridden things with a white list on your end, why should you trust
claims seemingly coming from [email-masked]?

(Claims being "I got this message from [email-masked]" headers in
the message body.)

> valid users, then it does not sound like a typical spoof bounce attack.

Of course it's not a typical attack nowadays.  We're talking a weakness
in a system that's not yet in place, and how folks can exploit that
weakness.

No one's going to be attacking the weaknesses of a system before the
system is widely implemented, hence those attacks won't be they typical
ones right now.

> It also appears they do not appear on an IP blacklist. 

True.

> their message based upon a filtering result (not a blacklist).

That's one way, yes.  (I don't see a real difference between the results
of "a filtering result" and "a blacklist" btw.)

> Hence the need for BATV?

SES/BATV is a protection a *sender* can put up to prevent bounces to
their own domain--and it's fantastic for that!

But as a recipient, you can't use SES to solve a problem, because you
are powerless to tell the sender to re-send with an SES-signed return
path.  (Well, you could refuse all mail that doesn't have either
Classic-SPF PASS results or validated SES-or-BATV return paths.)

> The danger, as

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.

-- 
Mark Shewmaker
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Aug 2004 18:38:46 -0700

> 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.

> > They have done nothing wrong, and yet a listing based upon Sender-ID
> > claims they did.  As a result, their mail is stopped.  What is fair
> > or civilized about that?
> 

So is a judge.

> You always have a recourse of going to a better mail service provider.

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.  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.

> I don't know what "transparent interception techniques" you're talking

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.  

> 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?

> 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.  

> identified, that reputation system could tell you whether you can trust

No. You can NOT trust the PRA.  PRA is potentially comprised of a large
set of domains.  The domain indicated could be any of a few hundred or a
few thousand domains.  The recipient would be unable to determine when
this could be the case!

> from that PRA were said to be untrustable.

If you are the one claiming the PRA to be untrustworthy, how would you
know when it was safe to make such an assertion?

> by the onslaught of spam attempting to reach them.

Sender-ID does not provide safe measures for repudiation assessments. 
Sender-ID does not authenticate senders, it provides a sloppy sorting of
senders.  Sender-ID will not fend off the onslaught unless having more
folders is a defense.

> let them move to more lucrative (and hopefully more honest) pursuits.

Sender-ID does not help in this battle.  It is not a good tool but
advocates removal of good tools.  Sender-ID will not enable enforcement
of any policies, but will break mail and cause people to use more and
more mailboxes to identify themselves.  How does that help?

> > Based upon which reputation service?  These providers will spend their

The reputation service providers.

> Spending their scant time in court?  Talk about unfair and uncivilized! 

I agree.
 
> 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
[email-masked] and pass with flying colors.   

> between pseudonyms, (separate writing-versus-reading webs too

If you wish to have a basis for repudiation, start with an identity that
can better trusted.  How about
[email-masked]: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.

> It's the substandard solution available now.

This conclusion could be wrong.  It depends upon the level of exploit
and the relative traffic from the server.
 
> forgeries will end up with worse reputations than if they went to more

You are suggesting it is okay to block those that might share an MTA
server?  Better to use a crowded domain then?

> "[email-masked] is not trustable.

The PRA can not be trusted.  What assertion can be made using a tool
that can not be trusted?

> claims seemingly coming from [email-masked]?

There is no means to know the level of trust to place on these
assertions.  It would be foolish to think gaps in these assertions will
not be exploited. 

> (Claims being "I got this message from [email-masked]" headers in

You are assuming a mapping that can not be verified. There is no way to
know if that is a good assumption, even if it passes all the tests.

> system is widely implemented, hence those attacks won't be they typical

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.  As I said, BATV ends this without a
large adoption.

> Classic-SPF PASS results or validated SES-or-BATV return paths.)

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.

> > The danger, as stated, is that if only submitter were checked, it would
> > not matter what was contained within these headers and the user
> > would be under the false impression at least one of the headers had
> > been checked.  What had been checked will remain a mystery.
> 

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? 
The shortest path would be to stop at the EHLO domain and ask if the
>From is part of that set.

-Doug

---

From: Mark Shewmaker <[email-masked]>
Date: Thu, 12 Aug 2004 23:43:01 -0400

> 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.)

> 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.

That's simply the way things are.  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.

People will alter their opinions.  I'm sorry if that bothers you.

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.

> It is not the

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.

Or they'll go 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.)

> 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.)

> 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

Here's the idea in a nutshell:

1.  Postulate:

    Authenticating the return path is a separate
    sort of thing from authenticating the
    forwarding path of purported (re) senders.

    A.  Classic SPF validates the return path.
        SES/BATV validates the return path.

    B.  Sender ID attempts to validate the
        purported (re) senders, but only validates the
        latest purported (re) sender directly.

    C.  Phishing detection detection has to do with message
        body tests, not envelope tests, hence if it were to
        be included in one of Classic SPF or SenderID, SenderID
        is the logical choice.

        So there's a question of how to put such a test in SenderID.

2.  Postulate:

    Since Phishing/re-sender tests and return path bounce-a-bility
    tests are mostly uncoupled from one another, so should be one's
    response to a failing result of such tests.

    A.  If I get a message where return-path tests FAIL,
        then I should reject the message.

        It doesn't matter if the failure is determined via
        classic SPF tests, or via SES/BATV tests.

    B.  If I get a message whose contents (including body headers)
        show it to be internally inconsistent (a type of message
        corruption) or otherwise a type of internal forgery, I
        should reject the message.

3.  The type of phishing I'm addressing is where someone claims to 
    send a message in a body header From:'s name, but From: isn't
    okay with that.

    *OR*

    A later PRA claims to send a message in the name of a previous
    PRA, but the previous PRA isn't okay with that.

So I proposed a sender_agents modifier that allowed users to say that
they don't allow other people (PRA addresses) to speak for them in
general, and to give an exception list of addresses that do.

So if I got a message From: you, but with a Sender: of
good-friend-of-yours, I could do a query to see that you trusted this
good friend of yours, so that I should trust the message to be genuine
from your point of view, were I to trust that the message really came
from your friend.

That would mean that if I got the message directly from your friend, I
could trust it.

Or, if your friend sent the message to my old, trustable ISP, that
forwarded it to me, since you had whitelisted your friend going forward,
and I had whitelisted my old account at my old ISP going backwards,
those two trust chains meet without any PRA in between them, and I can
(mostly) trust the message that I ended up getting to be genuine.

Or, if you say you participate in sender_agents, and I get a message
with body-header From: you, but Sender: [email-masked], I know
I can reject the message, even if SenderID said it really came from
evil-person, and even if classic-SPF said the return-path was good. 
(Unless I had white-listed evil-person for some reason--but obviously no
technical solution can overcome poor judgement in choosing friends!)

Anyway, it's only slightly more complicated than that--in ways you can
guess really, to accommodate multiple forwards and mailing lists.

But the upshot of it is that sender_agents can stop phishing to a large
extent, among participating players.

(Ie, if paypal.com published a sender_agent modifier within an spf
record, recipients who took advantage of it could have messages they
would have received with body header From: [email-masked] and
Sender: [email-masked] rejected, ***without being dependent upon a
single blocklist to see that [email-masked] was untrustworthy***. 
However, they would be dependent upon blocklists or a keen eye to see
notice forgeries of the type of [email-masked], or
[email-masked] (with numeral 1 instead of letter L.))

> 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.

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.

> miscreants.

> The miscreant may be spoofing as

If someone else can spoof [email-masked], 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 fact that [email-masked] 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.

(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.)

> 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.

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.

> 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.

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.)

> 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.

> be foolish to expect cooperation if this were an attack.

Correct.

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.

> >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.

-- 
Mark Shewmaker
[email-masked]

---

From: Graham Murray <[email-masked]>
Date: Fri, 13 Aug 2004 06:12:44 +0100

> via that IP, by just 10%.  Goofy wording, but you get the idea.)

This is an area where those most vulnerable to phishing or forging (eg
financial institutions, eBay, eCommerce sites etc) could help. If they
were to always send mail from their own (non-shared) servers, which
are identifiable as theirs in domain name, rnds and whois (on the IP
address), it would make it much easier for the recipient systems to
apply checks. If the PRA and reverse path say it comes from
[email-masked], the EHLO and rDNS of the connecting IP are
mailserver.bigbank.com then it is much easier to assign trust than
if the EHLO and rDNS are mailer3.outsourcingcompany.com. I have
received (genuine) emails from financial institutions and retailers
(who have both bricks and mortar and online sales) which have been
sent 'on their behalf' by public relations companies. I think using
third parties to send such emails is not helping at all in the fight
against phishing. So the solutions are not just technical, the senders
who want a good reputation will have to adopt safe procedures as
well.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Aug 2004 10:57:00 -0700

> 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.

> 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. 

> 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!
> 

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.

> companies like that--companies that won't admit, stand behind, and

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.

> 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.

> See:  http://www.imc.org/ietf-mxcomp/mail-archive/msg03112.html
<snip>

I see.  Identified Internet Mail seems a much cleaner solution.

> 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.

> such vulnerabilities.  It's unfortunate if I can be prosecuted for such

Blocking mail is not a thought crime.

> domain, because any claims of anyone to be from there aren't, well,

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.  

> 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.

> 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.

> 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.

> 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.  

> 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. 

> 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.

> BATV and SES only help for domains in which the purported sending domain

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.

> 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

---

From: Mark Shewmaker <[email-masked]>
Date: Fri, 13 Aug 2004 18:34:01 -0400

> 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?

> 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?

> The provider guarding against abuse does not
> 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.)

> 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.

> 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.

-- 
Mark Shewmaker
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Aug 2004 18:30:44 -0700

> 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.

> 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 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.    

> 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.

> outbound MTA if that single server doesn't allow cross-customer

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

---

From: Graham Murray <[email-masked]>
Date: Sat, 14 Aug 2004 06:53:32 +0100

> domains just to suit Sender-ID repudiations.

When an MTA serves multiple domains, either all of the email is
originated on the MTA and all of the domains are under common
ownership - which is possible but I suspect uncommon. In which case
the problem is internal to the running of that system and outside the
scope of this WG. Or, the emails are passed to the MTA, or MSA on the
same system, by SMTP clients on other systems. Therefore, could (and
should not) the shared MTA perform checks to ensure that the
submitting system is authorised to send mail for the domain in the PRA
of submitted email. Could the shared MTA not set up a 'private'
(internal either to the MTA or to the origanisation running the MTA)
DNS containing SPF, Sender-id or Domain-key records to indicate which
systems are authorised to submit email (to the shared MTA) on behalf
of each domain? Or, even easier especially where mail is submitted
from dynamic IP addresses, require SMTP AUTH and have a separate
authorisation 'user' for each domain.

---

From: Mark Shewmaker <[email-masked]>
Date: Sat, 14 Aug 2004 02:41:38 -0400

> tool used to help abate abuse.

And again, how am I taking that away?

> 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

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

You are the one insisting that that is the intent.

> 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.

> 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.

> 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
[email-masked]

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 14 Aug 2004 07:51:02 -0700 (PDT)

> authorisation 'user' for each domain.

Which domain is to be isolated by the provider?  Now, in addition to the
onerous limitations of the closed Sender-ID records for domains the
customer may employ, (closed as this shared mode then requires) you want
the provider to place a more severe restriction of a single domain
regardless of the Sender-ID record?  Either providers decide to endure the
expensive overhead and check each message's Sender-ID record and sign
contracts with Microsoft, or do nothing.  Either way, there is no
indication what was done nor that the MTA is shared.  If some identity
then becomes unfairly indicated to a repudiation checker, who is at fault?

The message will likely say "Message blocked by company 'X' repudiaton
services."  Will company 'X' claim provider 'Y' MUST use Sender-ID?  In
other words, 'Y' MUST sign contracts with Microsoft or they become a party
to the suit?  I don't see how Company 'X' is protected assuming the world
is using Sender-ID, especially when everyone is prohibited from using
Sender-ID unless a contract is signed.  Even if this were a free
technology, there is still no method to check if the message had been
checked at every shared point nor the related safety of an open record.

-Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 14 Aug 2004 08:48:56 -0700 (PDT)

> 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?

> 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?

> 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 would seem such advice should be found in the draft.

> 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.

> 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>
> 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>
> 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.

> 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

---

From: Meng Weng Wong <[email-masked]>
Date: Sun, 15 Aug 2004 23:31:46 -0400

On Thu, Aug 12, 2004 at 11:43:01PM -0400, Mark Shewmaker wrote:
| > 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

I think sender_agents is a fine idea, but because it can be
implemented as an optional extensionl, you might want to
write up a draft that describes the modifier and see how
people like it.