Subject: RE: Is the back door open?

From: Ryan Ordway <[email-masked]>
Date: Wed, 28 Jul 2004 09:11:21 -0700

> From: Andrew Newton [mailto:[email-masked]]

> Why do you need a list of valid users to do a Sender-ID check?

	Without a valid list of users, a mail gateway
cannot simply reject a message to domains it is
responsible for. For example:

	fleeblebur.org, let's say, has 3 MX hosts,
ralph.fleeblebur.org with a priority of 0, fred.fleeblebur.org and
bob.fleeblebur.org both with a priority of 10. ralph
may have a valid user list, being the primary MX host
which will handle the majority of mail. fred and bob
may not, being simply configured to spool mail until
ralph is back online.

	In this scenario, now that a given message is
coming from trusted hosts, will Sender-ID be effective?

	Ryan

--
Ryan Ordway
Sr. Unix Systems Administrator
@Once, Corp.
Email: [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Wed, 28 Jul 2004 13:11:24 -0400

> coming from trusted hosts, will Sender-ID be effective?

Are you saying that ralph cannot trust the data coming from fred and 
bob?  If so, then there is a larger problem here.

CSV could help this, but its utility here is allowing ralph to convert 
its IP-based whitelist to a domain-based whitelist.  I assume that CSV 
is being designed for inter-domain MTA authentication/authorization 
because intra-domain problems can be solved in other ways (some that 
need no standards work and others that are already standardized).

Regardless, what is stopping ralph, fred, and bob from doing Sender-ID 
or SPF checks?

-andy

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Jul 2004 10:58:52 -0700

> bob?  If so, then there is a larger problem here.

Only that messages are stored and then forwarded.

> need no standards work and others that are already standardized).

Although CSV could help make these intra-domain configurations safer,
the problem was about how a resulting bounce is handled.  Remember,
Sender-ID ignores the RFC 2821 MAIL FROM.  The defense against the
bounce that once justified publishing these records has been removed by
the PRA algorithm.  

> Regardless, what is stopping ralph, fred, and bob from doing Sender-ID 

If these checks are not done as messages are received, or where the
sender is spoofing a domain with an open list or no records, then even
with the checks, the mail is accepted and then bounced.

-Doug

---

From: Rand Wacker <[email-masked]>
Date: Wed, 28 Jul 2004 11:22:20 -0700 (PDT)

> bounce that once justified publishing these records has been removed by

Doesn't protection against the bounce using SPF-Classic require 100%
adoption to make it work?  Wouldn't BATV or some other site-local
protection against joe-jobbing have a more direct impact on this problem
(which, I will note, is not necessarily the problem this group was
chartered to address).

-Rand

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 28 Jul 2004 17:47:28 -0400

> bob?  If so, then there is a larger problem here.

  I think Doug's point is more that information necessary for the MX
to implement Sender-ID isn't distributed, but the incoming mail is.

  I won't get into issues of Sender-Id, but I haven't run an off-site
secondary MX for "striker.ottawa.on.ca" for about 5 years.  It was too
difficult for me to distribute & maintain my anti-spam rules to the
secondaries, so I just stopped using secondaries.

  From what I can see, many other domains have the same problem.  Most
of the mailing lists I run have messages which sit in the outgoing
queues for days, because the destination MX is flaky.  Over time, the
number of such messages has been increasing.

  One of the benefits of any MARID approach *should* be that secondary
MX's may now query & cache the MARID rules, which means that they can
apply those rules themselves... which means secondary MX's may become
more useful.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Jul 2004 15:06:18 -0700

> (which, I will note, is not necessarily the problem this group was

SPF offered some relief, if the MTA creating the bounce checked the
destination domain records for valid sources of the message.  This is
lost with Sender-ID.  A solution for this problem could be found through
a combination of SPF and BATV, where BATV is less disruptive.  SPF
accommodates an address based white-list, but such a list would be of
less use, with CSV offering names.

Should end-users or the MTA make accept/reject decisions?

The forward/reverse model for MX records is not symmetrical. Some
'forward path' is visible, but this view is not comprehensive. 
Rejection based against a sending domain's 'reverse path' is daunting,
but must be comprehensive.  Rejection based upon a sending host-name
falls within an achievable realm for DNS, and ideally accomplished with
a single query, as with CSV.

The host-name relationship broadens to the sending domain within the
realm of accreditation.  The quest for a 'reverse path' still does not
permit a decision of whether to reject the message, if to avoid abuse. 
A quest to examine content only weakens a decision process with
complexity.  The decision whether to reject the message is best based
upon RFC 2821 information.  The result should not be a rating for an
end-user disposition of messages.  It would be hard to twist the charter
to arrive at that goal.

A standard method to sign RFC 2821 MAIL FROM paths, as with BATV, would
end schemes used by rogue mailers to skirt accreditation.  This skirting
takes advantage of MTAs that do not employ history, and a reason for
many spoofed addresses.  If the sending domain has a history, acceptance
is based upon the sending domain's demonstration of policy.  If the
sending domain does not have a history, then mail could be constrained. 

For economies of scale, the burden must be placed upon the sender.  This
burden would result from their history of behavior.  If the sending
domain is rejected as a result of their accumulated history, then it
becomes their burden as the sender.  It must not be seen as a problem
for the end-user to sort, filter, and delete.  Grading makes mail
unreliable and eventually useless.  History based accreditation is best
done with a known name of the sending domain responsible for policy. 
This is the specific aim of CSV.  To stop spam or viruses, the question
remains, what is the history of the domain?

Construction of a partial 'reverse path' or examination of content for
filtering does little to abate abuse.  The quest for 'reverse path'
based grading begs for restrictions upon end-users to a limited choice
of a mailbox, or forces exposure of an additional mailbox, while
breaking many programs.  Freedoms offered by mail can be preserved,
rather than sacrificed for new folders in a mailer program.  These
introduced identities resemble a shell game, where the end-user guesses
the significance of different headers, most unrelated to the author of
message.  There are straight forward and strong means to identify the
author that do not break mail.

Sender-ID does not identify which domain allowed introduction of abusive
mail.  There can be no solution without this information.  If a domain
demonstrates a history of neglect, then a growing number of rejected
messages will make economic sense for polices to be repaired.  Sender-ID
is useless in this regard.  Put the burden upon the sender, and not the
recipient.

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Wed, 28 Jul 2004 18:13:55 -0400

> to implement Sender-ID isn't distributed, but the incoming mail is.

I understand this point.  I just don't think it is valid because it 
assumes that the "To:" identity (either 2821 or 2822) is part of the 
Sender-ID (or SPF) equation.  Why does an MTA need to know the "To" in 
order to check the "From"?

> secondaries, so I just stopped using secondaries.

This is my experience as well.

> apply those rules themselves... which means secondary MX's may become

I agree.

-andy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Jul 2004 17:11:21 -0700

Andrew,

AN> I understand this point.  I just don't think it is valid because it
AN> assumes that the "To:" identity (either 2821 or 2822) is part of the

There is no such thing as an RFC2821.TO identity.  So, what are you
referring...to?

>> apply those rules themselves... which means secondary MX's may become

Seems to me there should be a discussion about the implications of
having distributed rule-processing engines.  For example, where do we
have related experience, such that we can understand the dynamics and
administration, and have any hope of expecting this stuff to scale?

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jul 2004 00:19:31 -0700

> order to check the "From"?

Sender-ID checks the Purported Responsible Address (PRA) and may not
include the RFC 2822 From.  Sender-ID does not check the RFC 2821 RCPT
TO or the RFC 2822 To.  Such checks are done independently.

The scenario described was to illustrate a generation of a bounce
(resending of the message to the RFC 2821 MAIL FROM) rather than an
immediate message rejection with a 5xx error.  The bounce occurs, in
this case, when the mail is being relayed by an MTA that does not have a
list of valid users, but is only checking the right hand side of the RFC
2821 RCPT TO address.  If the message is initially accepted and then the
user is later discovered not valid, the message becomes bounced.

Acceptance does not require a full rating from Sender-ID, and may not
include a full set of other checks at that time.  Sender-ID acceptance
could be achieved using a domain with either none, open, owned, or
borrowed records.  A relay MTA may also opt to turn off Sender-ID
channel checks.  The bounce can emerge with a high Sender-ID rating
however.  If just the RFC 2822 From is used in the spoof, then the
bouncer becomes the PRA.  If the RFC 2821 is not null in the bounce,
then this would appear to originate from the bouncer.  (Some virus
filters seemingly want to advertise their post acceptance detection and
put something in RFC 2821 MAIL FROM bounce.  Bet such companies will use
'open' records.  Often the virus reported is listed on their website as
known to spoof the RFC 2821 MAIL FROM, and so they pass it along, like a
cat showing their prey.)

The 'reverse path' declarations needed for Sender-ID are not always
comprehensive, due to the extremely large scope involved.  There will
remain a population of 'open' records.  With the expense of DNS
wrenches, as a defensive posture, such Sender-ID checks could be
postponed until it is determined the mail is for a valid user.  Owing to
the overhead involved, Sender-ID checks could be reserved to benefit
just local users.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 29 Jul 2004 10:32:47 -0400

> administration, and have any hope of expecting this stuff to scale?

  We know DNS works, and scales.  I don't think anyone's arguing that
systems can maintain & publish their own MARID records.  So to the
rest of the net, those records in DNS look much like any other records
in DNS.

  The main differences between MARID and other kinds of data in DNS
are size and how much work the receipient puts into interpreting them.
These issues have been discussed for recipients, but not for MX
secondaries, because the topic of MX secondaries interpreting MARID
records hasn't come up.  It should be discussed in further detail.

  Hmm.. other than the "RCPT TO" issue Douglas Otis brought up, MX
secondaries aren't that different from any recipient SMTP server so
far as MARID goes.  The main difference is that it's more critical for
the MX secondaries to obtain the MARID information for a domain.

  As a related point, I've been part of a system which implements a
kind of distributed "pobox" via hesiod.  Each site publishes a list of
users@common-domain (which maps to a local email address), and each
site is listed as an MX for that domain.  They all do cross-queries
for hesiod information, so they all have the complete user list &
forwarding table.  Mail can then get queued on any site that's up, and
forwarded to the final destination by whoever received it.

  Alan DeKok.

---

From: Rand Wacker <[email-masked]>
Date: Thu, 29 Jul 2004 07:35:57 -0700

Douglas Otis wrote:

> destination domain records for valid sources of the message. 

Again though, this requires *every* MTA that might generate a bounce to 
deploy SPF checking, *everywhere*.

 > This is lost with Sender-ID.

This wasn't the goal of Sender ID.

> A solution for this problem could be found through
> a combination of SPF and BATV, where BATV is less disruptive. 

If an individual sending site deployed BATV wouldn't that let them 
determine what bounces were genuine and which were forged from the 
outside?  Why would they need SPF *at all* in that case?

> SPF accommodates an address based white-list, but such a list would be of

Doesn't Sender ID accomodate an address-based white-list as well? 
Specifically, addresses that users see/can see more readily than the 
Envelope From?

> Should end-users or the MTA make accept/reject decisions?

This question seems out of place.  But decisions should be made by some 
automated system, probably near the gateway, operating on behalf of the 
wishes of the admins/users.

> upon RFC 2821 information. 

For what technical reason is it best based on the 2821 address?

> sending domain does not have a history, then mail could be constrained. 

Agreed.

> remains, what is the history of the domain?

OK, I agree with everything you say here as well.  Doesn't almost every 
proposal put forth here (including Sender ID and DomainKeys) give you a 
verifiable domain to check the history of?

> mail. 

Without 100% publication of DNS records for sending domains, *none* of 
these solutions will be able to identify where all mail came from.

 > There can be no solution without this information.

We may be looking for solutions to different problems then.

> If a domain

Agree with the latter, disagree with the former.  Sender-ID can be used 
to verify the sending domain for purposes of reputation checks just like 
you say.  Is your concern with it the use of Resent-Sender and Resent-From

And, FWIW, neither SPF nor Sender-ID will ever be able to tell you any 
more than the most recent domain to forward a message to you, so in the 
case of messages that go through multiple hops to your gateway, you're 
going to be checking the reputation of any service that may be 
forwarding to you.

-Rand

---

From: Andrew Newton <[email-masked]>
Date: Thu, 29 Jul 2004 11:53:00 -0400

On Jul 28, 2004, at 8:11 PM, Dave Crocker wrote:
> There is no such thing as an RFC2821.TO identity.

Then we needn't worry about using a valid list of users when doing 
Sender-ID or SPF checks then.  :)

> less use, with CSV offering names.

I was under the assumption that BATV was a much better fit with domain 
keys than with SPF.  Actually, I have no idea what it has to do with 
SPF at all.  BATV is an interesting idea.

> TO or the RFC 2822 To.  Such checks are done independently.

I'm glad there's agreement on this.  :)

> user is later discovered not valid, the message becomes bounced.

I understand the scenario.  And I keep asking, "why not just do a 
Sender-ID (or SPF) check and REJECTION at the first MTA"?  And you keep 
saying, "It doesn't have the list of valid users."  And I keep asking, 
"what does a list of valid users have to do with a Sender-ID or SPF 
check?"

> borrowed records.

huh?  what?

>   A relay MTA may also opt to turn off Sender-ID
> channel checks.

Well, that is between you and the people you list in the target of your 
MX.  A relay MTA may also opt to block 0/0, but that's no fault of 
Sender-ID or SPF.

Are you trying to say that Sender-ID checks will only be one part of a 
spam-filter evaluation that can only take place on the delivery MTA?  
If so, isn't this your responsibility to handle properly since step 6 
of the PRA says "SHOULD" reject (meaning, if you didn't, you really 
ought to know what you are doing).

-andy

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jul 2004 12:52:59 -0700

On Thu, 2004-07-29 at 08:53, Andrew Newton wrote:
> > lost with Sender-ID.  A solution for this problem could be found 
> > through a combination of SPF and BATV, where BATV is less
> > disruptive.  SPF accommodates an address based white-list, but such
> > a list would be of less use, with CSV offering names.
> 

BATV uses DNS DomainKeys for a method that could allow the bounce to be
prevented in much the same manner as SPF would have done.  The
difference between SPF and BATV would be the method used to authenticate
the originating domain.  SPF would use a number of DNS TXT records to
compile a "comprehensive" or "closed" list of addresses of all outbound
SMTP servers sending messages using the domain of RFC 2821 MAIL FROM to
prevent the bounce.  BATV could authenticate the domain using a DNS
DomainKey to prevent the bounce.  BATV provides no assurance of the RFC
2822 From, nor does SPF.

> > this case, when the mail is being relayed by an MTA that does not have 
> > a list of valid users, but is only checking the right hand side of
> > the RFC 2821 RCPT TO address.  If the message is initially accepted
> > and then the user is later discovered not valid, the message becomes
> > bounced.
> 

I attempted to explain this in the following two sentences.

> > could be achieved using a domain with either none, open, owned, or

The spammer only needs to have the message accepted by the Sender-ID
check.  The rating for the check does not matter, provided the message
is accepted.  This could mean the domain claimed by the PRA which would
be:
  First RFC 2822.Resent-Sender else
  First RFC 2822.Resent-From else
  Singular RFC 2822.Sender else
  Singular RFC 2822.From

and receives a Sender-ID rating:
 Pass (+)
 Neutral (?)
 SoftFail (~ may accept messages)
 TempError (transient DNS or format error, may accept messages)
 PermError (unrecoverable format error, may accept messages)
 None (no records)

Those publishing records may include "+all" or "?all" as a method allow
their record set to be less than comprehensive.  Creating a
comprehensive record set could be daunting, with a limit of just 100 or
so DNS lookups with just 10 calls to Check_Host().  : )

If the bouncer has published their SPF record, then the bounce may
receive a Pass(+) rating. : (

> MX.  A relay MTA may also opt to block 0/0, but that's no fault of 

No. Bounce traffic is from a third-party beyond the control of the MTA
receiving the bounce.  This is not between related parties.

> spam-filter evaluation that can only take place on the delivery MTA?

No. The Sender-ID rating system directs mail into different folders
(rat-holes), and leaves to the end-user the task of sorting and
deleting.  The goal should be to have the message either rejected
outright or placed into the inbox.  If there is a problem, it can be
discovered and resolved, at the expense of the sender.

The Sender-ID approach seriously degrades reliability of mail in a
systemic fashion, and puts a much greater burden onto the recipient.  It
does not really stop phishing, bounces, or spoofing.  It does not
identify the domain responsible for the introduction of the abuse.  It
does not allow a means to control such introduction.  It does break
forwarding.  It does break mail "exploders". It does cause users to
change their mail address.  It does cause users to expose more of the
mail addresses.  It does put mail and DNS at risk.
  
> ought to know what you are doing).

That would be for resolving the PRA.  If a spammer can't get past the
test of creating a valid header, then it should be rejected.  I would
not expect the learning curve to be all that steep however, for this
test to stop that much abuse. 

Imagine how credit cards would be handled, if there were no means to
authenticate the identity of the person presenting the card.  Imagine
the amount of fraud there would be, if were no accreditation system. 
Why dream up methods to sort fraud?  Stop it!  Verify the name of the
sending domain.  Remember that domain if there was fraud.  Take action
based upon the history of that name.  An accreditation service could
make this process simple, but an MTA being administered with strict
policies can make a significant reduction in this mess by just creating
a history based upon names.  No name or no history, offer only
constrained service to limit damage.  If there was damage, remember it
or report it to the accreditation system.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jul 2004 17:09:55 -0700

> deploy SPF checking, *everywhere*.

I did say some.  BATV would allow more immediate benefits as it could be
acted upon by either end.  It would be more effective at the sender,
however.

> This wasn't the goal of Sender ID.

We agree Sender-ID does not stop the bounce.  I'll bite, what is the
goal of Sender-ID? 

> outside?  Why would they need SPF *at all* in that case?

Not everyone uses a null RFC 2821 MAIL FROM when they bounce. 
Determining a bounce then requires RFC 2822 checks of the From or
Subject headers. This is not a solid basis for rejecting a message
however.  The act of the bounce is best known by the sender, in this
case.

> Doesn't Sender ID accommodate an address-based white-list as well? 

Is the PRA the same as the RFC 2821 MAIL FROM?  Of course not.  The
check needs to be based upon an assertion made by the list.  A goal to
block the bounce, if the return path is spoofed, can not rely upon a
list intended for a different purpose.

> wishes of the admins/users.

How are the results of this decision reported to the sender?  Will mail
simply go missing, if placed in a folder flooded with other junk?

> For what technical reason is it best based on the 2821 address?

The EHLO domain allows for a stronger level of authentication and
authorization, than an RFC 2822 identity allows (without the aid of
digital signatures) as the EHLO domain can be authenticated directly
against the remote address of the current connection.  Rejection based
upon RFC 2821 identities can also conserve network resources.  RFC 2822
identity checks will never conserve network resources.  Killing the
connection is not a suitable solution as some advocate when rejection is
based upon an RFC 2822 identity.

The RFC 2821 MAIL FROM path is often spoofed as a means to skirt
accreditation checks based upon the remote IP address or, with CSV, the
name of the EHLO domain.  There is a need to curtail this practice. 
BATV could do this very quickly, but SPF did have merit in this
respect.  Sender-ID does not, as we agree.   

> verifiable domain to check the history of?

Sender-ID does not indicate the domain accountable for permitting access
to the mail channel.  Sender-ID can not check against the source of a
message, if introduced inside an administrative network or region of
MTAs.  As such, it would be impossible to attribute any domain as being
accountable, as this presumes an unverifiable assumption of security. 
Also, as shown by a Sender-ID bounce technique, the wrong domain could
be credited for sending the message.  It is also very likely, the domain
assertion would be nebulous.  What does ~, ?, +all, TempError, or
0.0.0.0/32 mean with respect to accrediting a domain?

In the case of the BATV and a DomainKey, that is missing is a nounce.  A
short term blacklist of timestamps with BATV would exclude a 'replay'
attack, but could not be used to accredit the domain.  The Yahoo
DomainKey or Cisco Identified Internet Mail signatures of the message
would be strong enough to accredit the domain.  These schemes would
still benefit from a lightweight check of the sending domain however. 
Sender-ID itself may also need lightweight protections.

> these solutions will be able to identify where all mail came from.

Those systems that use CSV, will identify themselves as a source. If an
MTA wishes to enjoy name accreditation, perhaps to bypass filtering or
Sender-ID checks, there would be motivation for publishing the SRV
record that enables this method.  A name based accreditation could be
beneficial without 100% participation.  CSV-CSA is simple and does not
add a single DNS query beyond the current SMTP protocol.  CSV could
eventually amend RFC 2821 as a means to repair the current defect
preventing SMTP client authentication (with authorization added as a
means to thwart Trojans). 

> We may be looking for solutions to different problems then.

I'll wait to see if I can understand the goal of Sender-ID first.

> > If a domain demonstrates a history of neglect, then a growing number
> > of rejected messages will make economic sense for polices to be
> > repaired.  Sender-ID is useless in this regard.  Put the burden upon
> > the sender, and not the recipient.
> 
> you say.  Is your concern with it the use of Resent-Sender and Resent-From?

It would be a nightmare attempting to make sense of Sender-ID domains
from an accreditation perspective.  There are many ways Sender-ID itself
can be spoofed, not to mention many nebulous levels of Sender-ID
assurances about the domain.  I see problems with an algorithm that
ignores which header type was most recently applied.  I doubt anyone has
given this much consideration.  Spammers will be quick to exploit
exceptions and learn intra-domain relationships published in this
records.  Accreditation is about controlling access at the domain
level.  Sender-ID is about grading mail ignoring the channel granted
access.  These concepts are incompatible.  Would you allow a retailer to
complain about a bad credit card, if they never checked the identity of
the card holder?  

> going to be checking the reputation of any service that may be 

I see name accreditation or history as a means of establishing a chain
of trust.  A retailer not only trusts a credit card, they are trusting
the holder of the card.  In general, they are trusting the system
represented by the card.  Only administrators of domains permitting
access will be able to curtail high levels of abuse as seen today.  Just
as accreditation allows access to a credit card, the same approach can
work for mail.  Those domains that allow abuse, will themselves loose
access.  Showing little history could mean little access.  This is a
model that works.  If there is a crime, there is also an authenticated
and authorized domain name holding the logs with CSV.

-Doug

---

From: Rand Wacker <[email-masked]>
Date: Thu, 29 Jul 2004 17:45:52 -0700 (PDT)

> acted upon by either end.  It would be more effective at the sender,

Right, so it seems that BATV could be a *much* better solution to the
joe-jobbing solution in the short term than SPF, precisely because BATV
requires adoption by exactly *one* site, the sender that wants to discard
bounces to them of forgeries.  To completely solve joe-jobbing for any one
site, SPF requires 100% adoption across the entire Internet.

(This is not to say that SPF may have other good properties, I'm just
hearing a lot of "its all about stopping joe-jobbing" comments)

> We agree Sender-ID does not stop the bounce.  I'll bite, what is the

I refer you to the MARID charter and the marid-core draft.

> digital signatures)

The RFC 2822 identity in a message is *exactly* the same regardless of
whether it is authenticated by a crypto-based solution, an IP-based
solution, or not authenticated at all.

We are definitly talking about two different goals, as I want to
authenticate the sender of a message, you want to authenticate the owner
of a channel.

> to the mail channel.

True.  But again, that is not its goal.

> Sender-ID can not check against the source of a message

The *original* source of a message.  It can check against the *most
recent* source of the message, to exactly the same level of assuredness as
SPF or any other IP-based system.

> from an accreditation perspective.

When I say "accreditation and reputation checks" I am referring
specifically to querying a network service to ask about historical
behaviour of the particular sending domain.  Based on previous comments I
think you may be using accreditation to mean something different.

> and authorized domain name holding the logs with CSV.

I still think we are using the term "accreditation" differently, but I
believe we agree on one thing here, making domains more accountable for
the mail they send.  I *think* that you want to do this by authenticating
the channel the domain used to inject a message in to the system.  I want
to do this by authenticating the user-visible address purports to be from.

To be blunt, I think everyone who has actively participated in this group
understands that *any* IP-based solution applied at *any* level can *only*
give you assurance of the most recent hop that a message took.  This
applies to CSV, SPF, and Sender ID.  This has implications for any message
that takes more than one hop from the original sending domain to the final
receiving domain.  All the proponents of these IP-based solutions
understand this and are moving forward knowing full well that they are not
able to authenticate the original sending MTA, domain, or author.

-Rand

---

From: Andrew Newton <[email-masked]>
Date: Thu, 29 Jul 2004 21:25:07 -0400

> receive a Pass(+) rating. : (

This is getting repetitive.  Why is it bouncing and not rejecting?

> receiving the bounce.  This is not between related parties.

And this is NOT the ralph, fred, bob scenario you started with.  So now 
we are back to receiving a bounce out of the wild, blue yonder?

> deleting.

It does?  I'll admit that I'm juggling multiple working groups and 
umpteen various drafts between them, so I could have missed it.  But 
where is that written?

>   The goal should be to have the message either rejected

So where does Step 6 fail on this?

> systemic fashion, and puts a much greater burden onto the recipient.

This is an unproven statement.  Repeating it doesn't make it come true.

>   It
> does not really stop phishing, bounces, or spoofing.

What new data do you have on this that can be added to past discussions 
of what some MUA's do and do not display to the users?

>   It does not
> identify the domain responsible for the introduction of the abuse.

No, it identifies the domain which will undergo a forgery check, just 
like CSV and SPF.  In the abusive case, all 3 do not identify the 
domain responsible for the introduction of the abuse.  A spammer need 
not have purchased a domain to forge another.

>   It
> does not allow a means to control such introduction.

What about SUBMITTER?

>   It does break
> forwarding. It does break mail "exploders".

In some cases, yes.  So does SPF.  CSV doesn't.

>  It does cause users to
> change their mail address.

What?

>   It does cause users to expose more of the
> mail addresses.

What?

>   It does put mail and DNS at risk.

This is another unproven statement.

-andy

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Jul 2004 21:13:28 -0700

> I refer you to the MARID charter and the marid-core draft.

The core-02 abstract:

 Internet mail suffers from the fact that much unwanted mail is sent
 using spoofed addresses -- "spoofed" in this case means the address
 is used without the permission of the domain owner.  This document
 describes the following:  mechanisms by which a domain owner can
 publish its set of outgoing MTAs, mechanisms by which SMTP servers
 can determine what email address is allegedly responsible for most
 proximately introducing a message into the Internet mail system, and
 whether that introduction is authorized by the owner of the domain
 contained in that email address.

 The specification is carefully tailored to ensure that the
 overwhelming majority of legitimate emailers, remailers and mailing
 list operators are already compliant.

CSV publishes outgoing SMTP servers.  A "spoofed" address for most would
include the RFC 2821 MAIL FROM, but yet this address is ignored.  CSV
and BATV meets the goal of finding prior compliance far better than
Sender-ID.

Now here is an interesting sentence fragment.

 mechanisms by which SMTP servers can determine what email address is
 allegedly responsible for most proximately introducing a message into
 the Internet mail system, and whether that introduction is authorized
 by the owner of the domain contained in that email address.

Clearly, in the case of a bounce containing Resent-Sender, Resent-From,
or Sender, this proximal goal is missed.  Also, can Sender-ID claim to
have met this goal, if the rating is other than Pass or Fail?  No, and
yet there are many rating levels?

Sender-ID allows mail to traverse or be emitted by many differing
domains of those referenced by the PRA.  It would be an over statement
to suggest permissions of the PRA can be verified with any certitude. 
SMTP is simply not secure enough to make this assertion, especially when
the specific SMTP server domain is ignored.  There are methods that can
safely reach to the RFC 2822 From.  Methods like Identified Internet
Mail can accomplish this goal, with the requisite certainty.  Sender-ID
can not.

> solution, or not authenticated at all.

An RFC 2822 identity may relate to an IP address of an SMTP server, but
at far greater distances, if compared to the EHLO domain.  This is
important in both the immense scale required for such a relationship,
the complexity deriving the relationship, and the assumption of security
needed to assert the relationship.  Any claims of having verified or
validated the RFC 2822 From would be irresponsible, in my opinion.  The
PRA is not limited to just this From header, nor should the channel be
considered secure enough to make such claim.     

> True.  But again, that is not its goal.

I would expect an ISP response to the complexity of Sender-ID, would be
to add Resent-From to all outgoing mail.  This would allow customers to
continue normal habits.  To arrive at a point where a message can be
rejected or accredited, barriers must be removed that would prevent
certitude in that process.  A greater distance between the the
associations being verified, reduces this certainty.  Evidence of this
reduced certainty is documented by the many gradations that may result
with Sender-ID.  If the goal is to validate the RFC 2822 From, then do
this in a reasonable fashion.  The scope of any simple validation should
not extended beyond the most immediate, being the MTA in this case. 
This is the charter, is it not?  

> SPF or any other IP-based system.

I do not agree with that statement.  By not going beyond the host being
authenticated and authorized, there is a significant difference between
the quality of the assurance from CSV versus Sender-ID, if to establish
accountability of the entity granted access.  Access is the commodity of
accreditation and the tool to enforcement.

> behavior of the particular sending domain.  Based on previous comments I

With Sender-ID, I see a complex record set that may include many
different domains.  To suggest that I should accredit the domain seen in
the PRA misses the purpose of accreditation.  Accreditation needs to
assess the policies of the domain granting access to the mail channel. 
The scale of this task is great, but resolving to the user would be
overwhelming.  There is a cost associated with a domain, there is
virtually none for a user.  The scope of the accreditation must end at
the domain, and only relate to their access policies.  With Sender-ID,
these messages could be "granted permission" by any number of domains.  

> to do this by authenticating the user-visible address purports to be from.

The PRA is not always the user-visible address.  By looking to the
user-visible address, you miss what needs accreditation.  What domain is
negligent in their access polices?  Do their policies control access in
a manner that abates abuse?  Looking to the user-visible address makes
this assessment far more difficult.  Looking to the user-visible address
makes this assessment far less accurate.  Sender-ID does not offer the
tools needed to tackle the problem, as its assertions are too weak and
too vague to be acted upon.  It may be just fine, if the goal is to
select a folder.  That goal seriously erodes the integrity of the mail
system however.  It also places a greater burden upon the recipient.  It
does not protect the network.  It does not abate the abuse, because
accreditation has become even more difficult.          

> able to authenticate the original sending MTA, domain, or author.

To fully understand the scope of the problem, work only on what can be
assured.  Limit the reach to the most immediate with simple measures and
stop trying to indirectly authenticate the user.  SMTP was never
intended to preform this function.  BATV and CSV can make a dramatic
change without breaking mail, and can be put into play quickly.  We can
make a real difference,  if to recognize what is within our grasp, and
what is not.

-Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 29 Jul 2004 23:35:12 -0700 (PDT)

> This is getting repetitive.  Why is it bouncing and not rejecting?

The message is accepted by the Sender-ID check with some rating other than
Fail, but a more complete check of the local part of the address is done
subsequent to acceptance.  This name check fails, as intended, and the
message is bounced.  The same could happen with a virus.

> we are back to receiving a bounce out of the wild, blue yonder?

I had never used these names?  Sender-ID never checks the RFC 2821 MAIL
FROM.  The bounced message will use this unchecked address to return the
message.  This return path could point anywhere and thus the message would
appear out of the blue, as you would say, sporting a high rating.  With
headers able to trump the bounce From, a filter may have greater
diffculty, as the PRA local part could be anything.

> umpteen various drafts between them, so I could have missed it.  But

When asked at the Open Group forum at Boston, during a presentation by
Microsoft, they claimed the only result of the Sender-ID check was to sort
mail into differing folders with their new Outlook.  It does explain their
lack of concern about reusing a list not intended for this function, or
the lack of security of the channel.  It does not abate the abuse, it
simply tries to sort it into folders.

> So where does Step 6 fail on this?

You are referring to a process that selects the PRA?  Sorry, but I fail to
see that as having much to do with the rejection of messages.

> This is an unproven statement.  Repeating it doesn't make it come true.

Filtering in general degrades the reliability of mail.  If you have
experienced a failure of the mail reaching its destination without notice,
then you are likely the victim of a filter.  This happens and I have been
forced to ask many times for an examination of the spam folder.  Perhaps I
become sensitve to this problem.  I don't see Sender-ID as a solution for
many reasons, but especially when it encorporates filtering, without
addressing the source of abuse.

>> It does not really stop phishing, bounces, or spoofing.
>

It is not just a matter of what is displayed.  There are areas where any
shared MTA becomes an ample opportunity.  Any ISP that transparently
intercepts mail, will then place all their clients at risk of this
phishing or spoofing.  These clients may also lose mail, if they are
unaware of this practice and close their lists.  This intercept technique
does abate spam.  As Sender-ID does not, don't ask to have this practice
stopped to allow a weak phishing claim.  The bounce problem has nothing to
do with the display.  I would much rather see something like Identified
Internet mail rather than Sender-ID for this type of function.  There will
be fewer victims of fraud then.

>> It does not identify the domain responsible for the introduction of the
>> abuse.
>
> like CSV and SPF.

There is a difference.  CSV uniquely identifies the sending domain
granting access.  Sender-ID or SPF may identify a set of domains that may
have granted access.  This is significant, when accreditation is
considered.

> In the abusive case, all 3 do not identify the domain responsible for the
> introduction of the abuse.  A spammer need not have purchased a domain to
> forge another.

How does a spammer forge the hostname with CSV?  How does CSV not identify
the domain?

>> It does not allow a means to control such introduction.
>
> What about SUBMITTER?

Submitter is about the same as PRA, assuming PRA gets checked.

>>   It does break forwarding. It does break mail "exploders".
>
>>   It does cause users to change their mail address.
>
> What?

In cases where the user does not control the DNS, there may be no choice
but to change their RFC 2822 From to be accepted.

>>   It does cause users to expose more of the mail addresses.
>
> What?

In the case of Submitter, the user may expose two addresses to accomplish
this feat.

> This is another unproven statement.

Yes, I have not proved this statement.  I can do the calculations that
raise concerns.  I call that risk.  I have not seen any counter studies
either.  "That would be bad" does not suggest this matter has been
reviewed to any degree.

-Doug

---

From: Michel Bouissou <[email-masked]>
Date: Fri, 30 Jul 2004 09:39:32 +0200

> however.  The act of the bounce is best known by the sender, in this

What about the following idea :

- Suppose that our outgoing SMTP servers encode _all_ of their outgoing MAIL 
FROM with SRS, whether or not the message is a forward, and whether or not it 
initially comes from our own domain.

- Now we can reject all "bounces" (MAIL FROM: <>) that we would receive, which 
RCPT TO: wouldn't be a valid SRS address.

Because if this were a legit bounce, then it would be a reply to one of our 
own messages, and would thus go to a valid SRS address.

Looks simple, but what do you think ?

-- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: Bill McQuillan <[email-masked]>
Date: Fri, 30 Jul 2004 00:41:14 -0700

> authenticate the sender of a message, you want to authenticate the owner

But isn't Sender-Id trying to authenticate the sender of the message against
the IP-address of the most recent SMTP client?

Doesn't the IP-address represent a channel?

-- 
Bill McQuillan <[email-masked]>

---

From: Tony Finch <[email-masked]>
Date: Fri, 30 Jul 2004 13:09:12 +0100

> Looks simple, but what do you think ?

This is what BATV/SES/pick-your-name is about.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 2 OR 3 INCREASING 3 OR 4. FAIR.
GOOD. SLIGHT OR SMOOTH.

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 30 Jul 2004 06:24:20 -0700 (PDT)

>> Determining a bounce then requires RFC 2822 checks of the From or Subject
>> headers. This is not a solid basis for rejecting a message however.  The
>> act of the bounce is best known by the sender, in this case.
>
> - Suppose that our outgoing SMTP servers encode _all_ of their outgoing
> MAIL FROM with SRS, whether or not the message is a forward, and whether
> or not it initially comes from our own domain.

As SRS replaces the domain to match the forwarding SPF environment, the
return path attempts to colapse to two steps of this process.  If a
forwarding process does not perform this function, then the message is
rejected, as now the SPF environment is wrong.

Rather than rewriting the return path, the concept is to use a public key
found with DNS of the originating domain.  If verified to be of that
domain by the receiver, then the SPF environment check is not needed to
validate the return path before a bounce.  If the encoding is recognized,
such a check could be used to discard a bounce by the receiver.  This
would not allow a rejection of a replay message by the receiver however,
but then would not require 100% compliance for this to work through other
hops.

> - Now we can reject all "bounces" (MAIL FROM: <>) that we would receive,
> which RCPT TO: wouldn't be a valid SRS address.
>
> Because if this were a legit bounce, then it would be a reply to one of
> our own messages, and would thus go to a valid SRS address.

BATV always allowed that.  There are virus filtering programs and other
noncompliant applications that attempt to "bounce" with a non-null return
path.  If there were an encoding of the return path that could be
recognized and checked before the bounce were allowed, the sending side
would then be helpful getting rid of that class of traffic.

Not overly fond of SPF restricting user domains, I would rather see a
comment tag added to a resent-from header that validated the forwarding
domain using the same technique, if to reestablish the SPF environment.
This would be done, rather than placing this forwarding domain into either
the domain or localpart of the return path.  This would forgive domains
not publishing SPF records or adding SRS, unlike SRS.  As often said, I
think something like Identified Internet Mail would be a better choice for
identifying the user.

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Fri, 30 Jul 2004 10:02:32 -0400

> message is bounced.  The same could happen with a virus.

So you are explaining that a bounce occurs because something other than 
Sender-ID has happened, and therefore that is a problem with Sender-ID?

> FROM.

Ryan came up with the names after you backed into the use case when I 
asked why it was there was a bounce in the first place.  You said there 
was a bounce because the mail was relayed to an MTA with the list of 
valid users.  Now you are back to the first use case saying that the 
bounce just happens for some mystical reason.  Ok fine.  But then that 
is not a flaw in Sender-ID, which is where this thread started.

> make a real difference,  if to recognize what is within our grasp, and

When you started this thread, I thought you were suggesting you had 
found a flaw in the PRA algorithm.  That is why I engaged in 
discussion.  Instead, this thread seems to have backed into the 
relative comparisons of CSV vs. SPF vs. Sender-ID, ground this working 
group has been over many, many times.  It is nothing new to find out 
that one proposal deals with forwarding better, one proposal deals with 
bounces better, and one proposal deal with phishing better.

-andy

---

From: "Sam Silberman" <[email-masked]>
Date: Fri, 30 Jul 2004 10:19:34 -0400

----- Original Message ----- 
From: "Michel Bouissou" <[email-masked]>
To: "IETF MARID WG" <[email-masked]>
Sent: Friday, July 30, 2004 3:39 AM
Subject: Re: The forged bounce question

> - Suppose that our outgoing SMTP servers encode _all_ of their outgoing
MAIL
> FROM with SRS,

The trick is to encode SOMETHING into the 2821.MAILFROM.    MUA/MTAs that
don't know the 'secret' can't forge the MAILFROM.   Take your pick of
encodings BATV/SES/SRS/whatever.

This argument is orthogonal to 2822 identity checking.    Those method do
not need to use the LHS of the 2821.MAILFROM.  Both methods should work fine
in tandom.

-Sam

---

From: Michel Bouissou <[email-masked]>
Date: Fri, 30 Jul 2004 16:30:25 +0200

> rejected, as now the SPF environment is wrong.

I don't quite understand your point, as you are mixing SRS and SPF. I was 
discussing SRS as a way to detect forged bounces, and this can work 
completely independently from SPF.

> Rather than rewriting the return path, the concept is to use a public key

Which concept ? There is quite a number of concepts discussed here ;-)

> BATV always allowed that.

As far as I understood (but correct me if I'm mistaken), a BATV address is 
replayable if it doesn't have a validity duration limit, which the draft I 
saw doesn't very clearly specify.

On the other hand, SRS addresses have only a limited validity in time, so they 
are replayable only for a short period, which would make them of no interest 
harvesting for spammers.

And bounce validity checking using SRS wouldn't need any public key to be 
published in DNS, nor any cooperation from the "bouncing side", it can be 
implemented by the "side receiving the bounce" alone, without any impact.

i.e. If I decide tomorrow to patch my MTA so that _any_ outgoing mail from my 
domain has an SRS <MAIL FROM>, and then that I will reject any DSN directed 
to any address other than a valid SRS address,  then I can close the door to 
any spam ou virus disguised as a DSN, as it wouldn't have a valid 
destination.

> There are virus filtering programs and other 

I have read this paragraph 5 times and don't get your meaning at all ;-)

Regards.

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 30 Jul 2004 11:27:32 -0700 (PDT)

>> > - Suppose that our outgoing SMTP servers encode _all_ of their
>> > outgoing MAIL FROM with SRS, whether or not the message is a forward,
>> > and whether or not it initially comes from our own domain.
>>

Validation is not limited to just the sending domain.

>> > - Now we can reject all "bounces" (MAIL FROM: <>) that we would
>> > receive, which RCPT TO: wouldn't be a valid SRS address.
>> >
>> > Because if this were a legit bounce, then it would be a reply to one
>> > of our own messages, and would thus go to a valid SRS address.
>>

BATV did include a timestamp.  I admit, the draft is just an outline.
There are several otheres working to make this draft more complete.

> On the other hand, SRS addresses have only a limited validity in time, so
> they are replayable only for a short period, which would make them of no
> interest harvesting for spammers.

It would prevent the return path being used to avoid accreditation.  It
would not prevent a replay attack to different MTAs spoofing as the
original message.  This would be assuming the return path was being
validated as part of the acceptance process.  That is not required for
this be useful.

> implemented by the "side receiving the bounce" alone, without any impact.

If the sending side could know when a return path was being used, that
would be good, if only to ensure the return path on the bounce messages
was null.

> i.e. If I decide tomorrow to patch my MTA so that _any_ outgoing mail from
> my domain has an SRS <MAIL FROM>, and then that I will reject any DSN
> directed to any address other than a valid SRS address,  then I can close
> the door to any spam or virus disguised as a DSN, as it wouldn't have a
> valid destination.

You will still be struggling with some of this traffic.  It will be
reduced.  As I said, not all of this traffic uses a null return.

>> There are virus filtering programs and other noncompliant applications
>> that attempt to "bounce" with a non-null return path.  If there were an
>> encoding of the return path that could be recognized and checked before
>> the bounce were allowed, the sending side would then be helpful getting
>> rid of that class of traffic.

If there were a recognizeable encoding of a return path (that would
indicate it to be a return path), then the sending side could help ensure
the message sent using this return path, would itself ensure this message
contained a null (MAIL FROM: <>) return path as a means to acknowledge it
was sending a bounce.

This concern is with respect to preventing double bounces.  If the
encoding is understood, and can be validated by the sender, and this is
discovered to be not valid, then the bounce can be dropped.

-Doug

---

From: Ryan Ordway <[email-masked]>
Date: Fri, 30 Jul 2004 12:26:26 -0700

On Jul 30, 2004, at 7:02 AM, Andrew Newton wrote:

> asked why it was there was a bounce in the first place.  You said 
> there was a bounce because the mail was relayed to an MTA with the 
> list of valid users.  Now you are back to the first use case saying 
> that the bounce just happens for some mystical reason.  Ok fine.  But 
> then that is not a flaw in Sender-ID, which is where this thread 
> started.
>
>
> that one proposal deals with forwarding better, one proposal deals 
> with bounces better, and one proposal deal with phishing better.

	Do we not want a solution that deals with each of these problems? I 
would rather spend a few more months having to wait for an adequate 
solution, rather than roll out a flawed solution and hope for the best. 
What would be the problem with addressing these issues now? And that is 
not a rhetorical question, I really want to know.

	Thanks,
	
	Ryan

[email-masked]