Subject: Re: draft-schlitt-spf-classic-01.txt

From: "Hector Santos" <[email-masked]>
Date: Wed, 1 Jun 2005 00:36:20 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Graham Murray" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 31, 2005 3:07 PM
Subject: Re: draft-schlitt-spf-classic-01.txt

> While
> possible, with add restrictions imposed by the email provider, the
> domain owner remains completely at the mercy of an email provider's
> diligence at _every_ MTA involved in the transport of the message, and
> not just those MTAs that have been directly authorized by the SPF
> record.  A mistake on the part of an email provider, such as
> misconfiguration of a firewall, and the domain owner's reputation
> suffers.

And how is CSV immuned from these same set of possible routing scenarioes?

Are you saying that once CSV authorizes a submission at the MSA, then there
is no need to further perform CSV during the route and only at the MDA?

What if you have this topology?

        MUA ---> MSA1/MTA1 -----> MTA2 ---->  MDA3

MSA1 and MDA3 is CVS ready.  MTA2 is not.

How does MDA3 handle this using CSV?  What is the policy here?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 1 Jun 2005 00:43:53 -0700 (PDT)

On Tue, 31 May 2005, Douglas Otis wrote:

> The HELO name would be indicative of the domain administrator running
> the MTA, irrespective of the mailbox-domains contained in messages sent
> by the MTA.  If the MTA is not properly administered, it would be this
> MTA and the administrator of this MTA identified by a reputation scheme
> that rates HELO names.

Doug,

People here are not saying that being able to tag responsiblity to MTA is 
a bad idea. People are just saying that there are also other ways it 
can be done and that MTA responsiblity is one thing while domain owner
responsiblity is another and that both are usefull when making decisions.

> Those that would normally send messages over a HELO blocked MTA would be
> free to look elsewhere to obtain email services.  If the mailbox-domains
> were rated and blocked instead, as with SPF, a poorly maintained MTA
> could continue to send abusive and even forged emails, but then the
> domain owners would find use of their domains blocked, no matter which
> other provider they tried.

I think what you're trying to argue here that when domain owner is using
shared MTA that does not have strong policies in regards to its network
than it may become target of abuse and abusers may choose to use other
domains maintained by that MTA at random, i.e. its the case of large dsl
provider and user having to use that provider's MTA and is subject to
the MTA being used by zombies located on the provier's networ and zombies
choosing domains of various users (that come through that mta) at random.
Is that what you're worried about?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 01 Jun 2005 14:19:34 -0400

"william(at)elan.net" <[email-masked]> wrote:
> domains maintained by that MTA at random,

  If an MTA is shared, the reputation would seem to be shared, too.
That's life.

  We could require that abuse of a shared MTA by one domain not affect
the reputation of another domain also at that MTA.  But we can't use
the HELO field as part of a solution to meet that requirement, as the
only information it presents is the name of the shared MTA.

  If the *message* is authenticated, and not the *transport* layer,
then it doesn't matter how the message is transported.  But that's
another issue...

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Jun 2005 12:01:40 -0700

On Wed, 2005-06-01 at 00:43 -0700, william(at)elan.net wrote:
> People here are not saying that being able to tag responsibility to MTA is 
> can be done and that MTA responsibility is one thing while domain owner
> responsibility is another and that both are useful when making decisions.

To authenticate the mailbox-domain, use a signature.  It is unfair to
hold the mailbox-domain owner accountable, when there remains doubt
about who actually initiated the message, as with SPF.  Dunning the
mailbox-domain owner for abuse can not be effective, when the source of
the problem is a mystery to them.  The only avenue available to the
mailbox-domain owner would involve a discovery process in an expensive
litigation, to force the MTA administrator to produce requisite
transaction logs.  Otherwise, the MTA administrator would be obligated
to keep these logs private, and may not be cooperative when the logs
indicate they were negligent in some fashion.

> the MTA being used by zombies located on the provider's network and zombies

Only by naming the actual source of abuse, not just finding a name to
blame, would reputation provide a means to ensure the MTA administrator
remains diligent.  Only a diligent MTA administrator can be effective at
squelching abuse.  The number of techniques used to circumvent security
is many.  Two rather obvious concerns would be open-proxy or open-relay,
which have specific dedicated black-hole lists for just these possible
administrative errors.  Some of these errors require third-party
real-time verification to isolate the source.  Hardly a legitimate duty
to be expected of the mailbox-domain owner.

In addition to normal security concerns, with SPF/Sender-ID, the MTA
administrator MUST apply mailbox-domain limitations based upon
permissions for either authenticated users or an MTA being relayed.
This will cost the MTA administrator support calls.  Because SPF depends
upon ambiguous defaults defining which identities are assured within a
message, SPF records may be used as a basis for applying the PRA or the
bounce-address.  Therefore, any MTA administrator failing to make the
same limitations for the PRA, as for the bounce-address, place the
mailbox-domain owner's reputation at risk.

The only safe option presently available for the mailbox-domain owner
would be to NOT publish SPF records.  Otherwise, the mailbox-domain
owner runs a serious risk of being assumed culpable for any forged
abusive messages that may appear.  With these SPF records being very
public, an already far too common nefarious abuser employing the use of
Zombied systems, will also know who they should try to forge.  Abusers
may be successful due to an MTA administrator's lapse in applying either
some or all of the expensive mailbox-domain restrictions.  Even if the
Zombied system were owned by the actual domain owner, the MTA
administrator is best able to detect abuse to alert the domain owner.

On a per-MTA basis, CSV ensures the administrator is held accountable
for the operation of the server.  It is foolish to hold a feckless
mailbox-domain owner accountable.  Signatures, while not providing any
network resource protection, do offer a fair and safe method to hold the
administrator accountable from where the message originated.  Signatures
can track the mailbox-domain and offer real anti-phishing protections as
well.  While there have been some to suggest Sender-ID offers
anti-phishing protection, it is not safe due to reliance on hidden
headers and server authorizations.

To increase the integrity and safety of email delivery, an
identification and reputation scheme needs to be as close to go/no-go as
possible. Otherwise, the junk folder becomes the nemesis of a large
number of gray transactions.  It is unfortunate that SPF has four levels
of server authorization.  This multilevel aspect has a multiplicative
affect on reputation assessments, as there may be a desire to track each
level separately to form some kind of proprietary fuzzy-logic
aggregate.  

As I said when I started my comments, SPF is fundamentally flawed.  SPF
and Sender-ID in combination is a disaster.  The filtering paradigm used
by SPF to handle its many shades of gray will ensure the problems
created will be intractable.  The only means I see to extricate SPF from
making things far far worse, would be to depreciate the use of version 1
SPF records.  Recommend that they be removed.  For those that don't want
to be trusting an MTA provider to assure their reputation, offer a new
scope called 'ADMIN' to allow SPF to be used for white-listing purposes
only.

Should SPF/Sender-ID reputation schemes become used as promised, there
will be a new industry servicing email forensics to assist a booming
civil discovery process.  The harm created will be intractable and
extremely damaging.  Domain constraints will cause a loss of customers
and enumerable support calls.  SPF/Sender-ID provides two very difficult
paths to choose, when attempting to avoid administrative accountability.
Adjust your budget accordingly, there is no free lunch.

CSV, on the other hand, indicates that you accept administrative
accountability without unfairly foisting this onto your customers.  Only
signatures offer an alternative that can safely apply accountability
from where the message initiated.

-Doug

---

From: Graham Murray <[email-masked]>
Date: Thu, 02 Jun 2005 08:16:45 +0000

>   If an MTA is shared, the reputation would seem to be shared, too.

If reputation is that important for a domain owner then they can always run
their own mail server(s) and not use a shared MTA.

---

From: johnp <[email-masked]>
Date: Thu, 02 Jun 2005 10:45:36 +0200

I run Postfix on a server, and anyone who wants a seperate MTA can have 
a seperate instance of Postfix running just for themselves, with a 
seperate IP. The rest of the server facilities are shared. I'm not sure 
if sendmail allows seperate instances to run similtaneously like this.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Jun 2005 19:53:31 -0700

>   If an MTA is shared, the reputation would seem to be shared, too.

I agree with William's statement.  With SPF or Sender-ID, reputation
accrual would damage a mailbox-domain owner, and not the MTA
administrator.  The mailbox-domain owner may have been singled-out and
forged by some zombied customer, until the victim's reputation is
thoroughly destroyed.

The administrator of a shared MTA must apply mailbox-domain constraints
on both the bounce-address and the PRA for each and every message.  This
constraint must limit the domains permitted for the authenticated users
or relayed MTAs.  Lack of this domain constraint operation imperils
their customer's domain reputation.  I doubt many email providers would
provide a virtual MTA with an isolated IP addresses, just to avoid the
need to assure this mailbox-domain constraint.  I have little doubt the
MTA administrator would do nothing, and consider this as not their
problem.

IP address space pressures has caused much of the sharing of IP
addresses for both MTAs and Web servers.  One reason to deploy a name
based reputation system, is to overcome the problem of IP address
aggregation affecting so many different domains.  The application of
reputation makes domain/user isolation critical for the domain owner.

> only information it presents is the name of the shared MTA.

The lack of HELO validation would not be considered a reason to reject
the message, based on either SPF or Sender-ID validation.  Had just the
MTA identifiers, IP address or HELO, been solely utilized as a basis for
accruing reputation, then indeed reputations would be shared by every
domain using the MTA.  Then the domain owner could recover use of their
domain by employing a different MTA.  Relying upon the MTA identifiers
for reputation accrual provides the MTA administrator an incentive to
aggressively disable abusive accounts.  They would maintain diligence by
either monitoring logs for volumes and errors, or by checking abuse
reports.  This incentive is real and valuable.

Once an MTA administrator buys the notion that SPF/Sender-ID takes care
of abuse, where reputation no longer affects them directly, they have
less incentive to do the real job of abating abuse before it is sent.
While this may be seen as a great feature by email providers, it should
cause network providers and any domain owner great concern.  Abusers
controlling millions of zombies will jump on this weakness, much to the
detriment of mailbox-domain owners sharing an MTA, and that have also
published SPF records.  Unless you run your own MTA and are willing to
allow some mail to be lost by those that have forwarding accounts, do
not publish SPF!  Consider DomainKeys for now, and then upgrade to DKIM.

> then it doesn't matter how the message is transported.  But that's

Yes it is.  That is the reason DKIM is so desperately needed.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 03 Jun 2005 12:47:04 -0400

Douglas Otis <[email-masked]> wrote:
> addresses for both MTAs and Web servers.

  What's up with 29/8 & 30/8?  There are 50M addresses unused.

>  One reason to deploy a name based reputation system, is to overcome
> the problem of IP address aggregation affecting so many different
> domains.  The application of reputation makes domain/user isolation
> critical for the domain owner.

  In the absence of DNSSec, using DNS names for reputation is a bit
problematic.  You're never completely sure that the domain is
currently being controlled by it's owner.

> less incentive to do the real job of abating abuse before it is sent.

  I'm not sure there's any technical solution to that problem.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Jun 2005 11:55:50 -0700

>   What's up with 29/8 & 30/8?  There are 50M addresses unused.

IP address conservation has slowed the rate of consumption.  Once these
addresses are fully assigned, reliance upon IPv6 becomes required.  As
with many things, preparation requires time to phase-in full support.
In the meantime, to allow communities early in their Internet deployment
a reasonable number of IP addresses, some addresses need to be reserved.
If each domain name required a unique address, this reserve would be
quickly exhausted.

> currently being controlled by it's owner.

DKIM creates far fewer DNS security concerns compared to SPF which
reduces some of these potential DNS problems, rather than adding to it.
For reasons actually unrelated to DNS, DNSsec should be deployed.  While
even DNSsec will not prevent every attack vector, it will expose more
attack efforts.  Hopefully, diligence and cooperation prevail in
cutting-off network providers that permit the coordination such
activities.

There is a need to establish a re-assignable ID number to identify those
that trade or use stolen identifiers.  By requiring a timestamped query
to a clearinghouse, to return to the requester a relevant static index
(pseudo SSN), would make this information far more risky for the
criminals.  The query may also identify abuse attempts.  There could be
many re-assignable ID clearinghouses used for various purposes.  

>   I'm not sure there's any technical solution to that problem.

The simple technical solution would be to _always_ base reputation
accrual upon "Authenticated Senders" and _never_ "Server Authorization."
Going down the list of identifies available that could isolate security
and abuse issues to the accountable administrator, it would be:
  - IP Address
  - Authenticated HELO Name
  - Validated Signatures

You will notice that the mailbox-domain is not in this list.  This
mailbox-domain identity is passed from MTA to MTA, and is unrelated to
an accountable administrator.  SPF or Sender-ID also makes a false
assumption that the MTA is not shared, or that the MTA administrator
ensures user/mailbox-domain relationships are protected.

I have yet to hear anyone caution domain-owners they should first become
indemnified in their provider's SLA, and be assured only their messages
are permitted to use their domain in the bounce-address or the Purported
Responsible Addresses, as defined in Microsoft's proprietary algorithm.
The penalties should be sufficient to cover loss of the use of the
domain.  This SLA should provide a means to verify any allegations of
negligence on the part of the provider.  Without this agreement, the
domain owner would be placing their domain's reputation in extreme
peril.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 03 Jun 2005 17:26:54 -0400

Douglas Otis <[email-masked]> wrote:
> You will notice that the mailbox-domain is not in this list.

  s/this/your/.  Not everyone agrees.

  I have vanity domains where I'm the only person with mailboxes at
the domain.  I *am* the accountable administrator for that domain, and
I would like to be able to state so.  I would like to be able to say
publicly that any message not from me, using mailboxes at my domain,
is forged.

  Some proposals allow me to do that.  The original purpose behind RMX
was exactly that: Hadmut had a vanity domain, and couldn't stop people
from forging messages using that name.  Hadmut was also very clear
that not everyone would want to use RMX, but the people who would use
it could protect themselves.

  The response then, as now, is that there is absolute opposition to
such proposals.  The requirement that we permit ".forward" style MTA's
to use third-party domain names is a requirement that people like
Hadmut and myself cannot prevent others from forging spam using our
names.

>   This mailbox-domain identity is passed from MTA to MTA, and is
> unrelated to an accountable administrator.

  Ah, yes.  If we assume the current behavior is desired, then the
conclusions are foregone.

  If, on the other had, we have the temerity to question the existing
assumptions, then the conclusions are questionable, too.

> SPF or Sender-ID also makes a false assumption that the MTA is not
> shared, or that the MTA administrator ensures user/mailbox-domain
> relationships are protected.

  SPF and related proposals allow the DNS administrator to claim that
the MTA satisfies certain criteria.  But this benefit is being turned
around, and claimed to be an accidental, and negative side-effect.

> are permitted to use their domain in the bounce-address

  For me, it isn't so much about permission as audit trail.  If I
can't prove a particular message using a mailbox address is actually
associated with that address, then I have no idea if the message is
forged or not.  Signatures don't help, as anyone can create a
certificate or key for any identity they want.

  What matters is the "web of trust", or the relationship.  Signatures
*can* help if the certificate for "[email-masked]" is signed by the
key for "example.com", and the key for "example.com" is signed by a
known CA.  In that case, the signatures are a means to an end, not a
solution in themselves.  They make the relationship management easy
and reliable, nothing more.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Jun 2005 18:07:27 -0700

On Fri, 2005-06-03 at 17:26 -0400, Alan DeKok wrote:
>  Not everyone agrees.

Those accruing reputations based upon evidence of abuse, have no way to
know whether the message was carried over a shared MTA or not, and in
the case of SPF version 1, whether the sender expected the
bounce-address or the PRA be used as a basis for acceptance.  If SPF
were used just to reject messages from unauthorized servers, which is
rarely the case due to path registration problems, indeed there would be
far less risk involved when publishing SPF records.

While some domain owners may run their own MTA and permit just their
domain to utilize the MTAs that carry their outbound messages, this
would not represent a typical case.  The outright blocking of messages
from unauthorized servers is often not practical either.  There will
always be cases where email is lost or refused, when attempting to
create such strict path registrations.  Lost messages can be problematic
whether for financial institutions or large network providers.

Recipients are left using a filtering paradigm that attempts to
establish acceptance thresholds for the multiple levels of authorization
presented by SPF.  The additional lowered levels of authorization
attempt to convey the likelihood a sender conforms to path registration.
Of course, there is no way to accommodate any forwarding that may
process their message.

While not everyone may agree, strict server authorizations and exclusive
MTAs represent special cases.  Even these special cases offer little
benefit in terms of phishing prevention.  The recipients willing to
dredge through often extensive path registrations, would be hard pressed
to realize a benefit, when the majority of messages reference open-ended
records, and no reputation is accrued.  There is the danger.  With SPF,
corner cases will likely find themselves in the junk folder, and those
that permit exceptions with open-ended records, may also find their
reputation damaged.  Those that share an MTA may also find their
reputation damaged and should demand indemnification from their
provider.

> assumptions, then the conclusions are questionable, too.

When today's systems are able to digitally sign messages without
requiring additional hardware, and can do so in the time needed to
dredge through path registrations, you should question schemes that
require wrenching changes to decades old and highly pervasive
architectures.  With signatures, you do not need your email provider to
swear they make mailbox-domain restrictions.

Path registration and mailbox-domain restrictions create a very bad
premise for basing a new reputation scheme.  This premise suffers two
very serious flaws.  It often fails to identify the accountable
administrator, while at the same time expects the administrator to
impose additional expensive limitations on the use of mailbox-domains.
At least warn the domain owner to ensure domain restrictions are in
place by the provider before publishing SPF records.

> around, and claimed to be an accidental, and negative side-effect.

There is nothing provided by SPF that indicates whether 1 or 1000
domains use an MTA or whether any mailbox-domain was initially checked
for that matter.

> certificate or key for any identity they want.

Either path registration or a key from DNS do not add any new identity
abstractions.  Not just anyone can create the path registration for the
domain.  Not just anyone can create a key for the domain.  Signatures,
unlike path registration, do not depend upon knowing beforehand the path
a message eventually takes, and hence will not break current email
architectures.

Unlike path registration, the private portion of the key is not exposed,
which provides the possibility for a stronger audit trail, than that
available with path registration.  The key itself could be used to sign
prior keys, as example.  Of course, this is similar to DNSsec.

> and reliable, nothing more.

While a CA would offer improved security, as would DNSsec for that
matter, DKIM relies upon the security of DNS the same as SPF does.  I
attempted to illustrate how doing non-recursive key lookups could be
used to establish a key audit, as an interim solution for DNSsec.  I
doubt such scheme will be employed, unless some exploit makes such
auditing required.  I described it in the
draft-otis-mass-reputation-01.txt draft to improve the chances this
concept would be available if needed.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 04 Jun 2005 05:34:27 +0200

Douglas Otis wrote:

> in the case of SPF version 1, whether the sender expected the
> bounce-address or the PRA be used as a basis for acceptance
                         __
                       /    \
                      |      |
                      |\____/|
                      (      )
                      |      |
                      |      |
                      |      |
                 __   ( (--) )  __
               / -- \ |      |/ -- \   _
              |      \|      |      \/ - \
              |       |      |      |     \
            / |       |      |      |     |
          /   |                           |
         (     \                          |
           \         \    |    /          |
             \         \  |  /            |
              \           |              /
               |                        |
                \                      /
                 |                    |
                 |                    |

---

From: Douglas Otis <[email-masked]>
Date: Sat, 04 Jun 2005 06:09:33 -0700

> > bounce-address or the PRA be used as a basis for acceptance

Who is really most deserving of this eloquent message?

Care to comment on this message? 
http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

Or, how about this message?
http://www.imc.org/ietf-mxcomp/mail-archive/msg05572.html

You are ignoring a reality that Microsoft has usurped the definition of
the v=spf1 record and clearly has this record in their pocket.  This is
evidenced by their clout at various email conferences.  The "bounce-
address" and not "PRA" version of SPF must be defined by the version 2
record.  The sooner SPF advocates accept this, the greater the chances
SPF will not morph into Sender-ID by way of a reputation trap.

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Sat, 4 Jun 2005 11:35:30 -0400 (EDT)

> publicly that any message not from me, using mailboxes at my domain,

And just what benefit is there to being able to do this?  

I too, have pet peevs: I would like cats to use the toilet--I am sure
there is benefit to that.  But I am not so sure it would be worth millions
of dollars and the significant additional harms such as are involved with
SPF.

Abuse targeted at one particular domain is enabled by SPF in spades---its
called 100% blowback.

Alan, you've been subjected to significant mail abuse in the past. I
understand that you'd like to prevent mail abuse.  But this abuse isn't
spam, and SPF won't solve the problem of people trying to mailbomb you:
SPF makes it worse.  You will get mailbombed by <insert large ISP here>'s
mail servers sending you bounces. This is called blowback. It happens a
little bit whenever mail is forged. SPF can make it happen 100%.  It would
be impractical to block <large ISP>'s mailservers, so the SPF blowback
problem is much worse.  In your case (and in many cases of email forgery),
the mail is forged in order to generate hate mail and otherwise annoy you.
__You__ are the target. __You__ are being harrassed.  Unfortunately, there
is no technical way for you to stop your harrasser's from harrassing you.  
It you take away one toy, they will use another.  In this case, you are
giving them a new toy that is much worse because it is easier to abuse,
generates more abuse per message, and is harder to prevent abuse.

I am writing a paper on why SPF is fatally flawed, since its proponents
haven't yet addressed or even acknowledged the analysis and flaws
previously raised on IETF MARID working group---and since I've also
recently learned that they have been spreading false rumors about 'why
things did not progress at the IETF MARID working group.' They've been
apparently been telling people that there aren't any technical problems
with SPF, and that things did not progress at the IETF for 'non-technical'
reasons.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 04 Jun 2005 12:55:32 -0400

Dean Anderson <[email-masked]> wrote:
> > I would like to be able to say

  I thought I had explained.  What part of my message was unclear?

> spam,

  You've been saying that for a number of years now, and during that
time, have had access to zero pieces of data from my domain.

  I've had others[1] look at the evidence, and I've looked at it
myself.  No one agrees with your assertions.

  Not one.

  Your position is based on something called "faith", not "reality".

  I'm not saying this to convince you, because I know I can't.  I'm
saying it to explain to everyone else reading this that your position
is not one to be taken seriously.

> In your case (and in many cases of email forgery), the mail is
> forged in order to generate hate mail and otherwise annoy you.

  How do you know the mind of the spammers?  Are you in contact with them?

  Alan DeKok.

[1] i.e. multiple people with long-term experience in the anti-spam
community, who've looked at 10^4 source IP's, 10^5 fake addresses "at"
my domain on spam CD's, 10^6 connection attempts, and/or 10^8
delivered messages.  No one agrees with you.  Not one.  Most do agree,
however, that I probably have the worst spam problem in the world.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 06 Jun 2005 14:59:29 -0400

Douglas Otis <[email-masked]> wrote:
> If SPF were used just to reject messages from unauthorized servers,
> which is rarely the case due to path registration problems, indeed
> there would be far less risk involved when publishing SPF records.

  So... why do "path registration" at all?  I'm still confused as to
why it's OK for people I've never heard of to send messages using my
mailbox address.

  When I send messages, my outgoing MTA looks up the MX record for the
domain of the destination mailbox, and sends the message to the
specified MTA.  Where's the path?

  If we had provable senders, and signed messages, then the path
problem would disappear.  If the transport layer, and application
message layer are both signed and accountable, then any MTA should be
able to transfer messages for any other MTA, and path problems become
moot.

> domains use an MTA or whether any mailbox-domain was initially checked

  Is that a problem?  Publishing SPF records indicates that the domain
owner accepts accountabilty for the behavior of the MTA.  Who cares if
the MTA has another 10^6 domains, or is run by a
<insert-prejudice-here>, or by a convict, or is in Iraq?  The domain
owner states the MTA is accountable, so therefore it is.

  This objection to SPF looks a lot like an objection to *permitting*
the domain owner to make such statements.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 06 Jun 2005 18:44:51 -0700

> why it's OK for people I've never heard of to send messages using my

Excellent questions.

> specified MTA.  Where's the path?

The possible network addresses of where a message can be delivered for a
specific domain may only be partially resolved in an MX lookup process.
Once a valid network address has been discovered, immediate delivery
would normally be to that network address.  Once delivered, the message
may then be passed on to several other locations, before arriving at a
mailbox destination.  Often you can not know this path, nor would you
normally care.

For some organizations, the outbound network address used to send
addresses may be unknown, which is the portion of the path that SPF
attempts to register.  Organization may sub-contract services, and these
often evolve frequently.  For some organizations, the complexity of
their email infrastructure is not readily accommodated in the 100+ DNS
records allotted by SPF.

> able to transfer messages for any other MTA, and path problems become

To some extent you would be correct.  There is still a need to protect
network resources, and this entails something other than a signature.
Protection requires authentication, or the integrity of the network
resource protection scheme would prove unsafe and unfair.  With email,
only the remote IP address or the HELO offers specific confirmation of
an actual source of a message.  Authorization can not be safely used to
infer the source of the message.

> owner accepts accountability for the behavior of the MTA.  Who cares if

While the domain owner will surely suffer the results of an MTA
administrator's lack of diligence, I would not expect any domain owner
has accepted this accountability.  I have heard time and time again,
admonishments that domain owners should ignore concerns in this regard.
SPF somehow magically protects them.  A shamefully false statement of
course.

There is even the matter of defining what being diligent entails.
Should the MTA administrator ensure exclusive use of the bounce-address
or does this also include the PRA.  There is no warning about publishing
an SPF record that includes the PRA scope.  The suggested dummy PRA
record by Sender-ID has already been declared to have limited value in
the future.  What then?

> the domain owner to make such statements.

The publishing of these records should include a disclosure as to the
potential negative impact this record may have with the domain's
reputation.  It should describe what actions are needed by the provider,
to ensure the domain owner's protection in the all to common case of
shared MTAs.

Importantly, there should be a way to use the SPF record that clearly
indicates what is being assured by the domain owner.  The lack of
consensus regarding the version 1 record makes excluding the use PRA
impossible.  Depreciate the use of Version 1 and express the scopes
found in version 2.  This would permit a means to positively exclude the
use of the PRA.  I also see value in being able to exclude the use of
any scope, to permit this record be used for white-listing only, for
example.

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Tue, 7 Jun 2005 11:55:27 -0400 (EDT)

On Mon, 6 Jun 2005, Alan DeKok wrote:

> I'm still confused as to why it's OK for people I've never heard of to
> send messages using my mailbox address.

This is a fallacy of false choice. Its the equivalent of asking if you've
stopped beating your wife yet. The question seems to permit two choices
(yes, you have, and implies you did before; or no, you haven't yet stopped
beating your wife)  Its a fallacy because there are additional
possibilities.

The false choice here is that if we don't approve SPF, we choose to permit
people you've never heard of send messages using your mailbox address.  
There is no such choice: SPF doesn't prevent anyone from doing that.

Lets try non-fallacy arguments.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 7 Jun 2005 12:02:00 -0400 (EDT)

> time, have had access to zero pieces of data from my domain.

Partly true. I have seen your mail statistics that you posted to the 
freeradius list. However, you did not take me up on my offer to assist you 
with those attacks, which included setting up an MX forwarder to screen 
(and analyze) abuse.

> myself.  No one agrees with your assertions.

Its not credible to claim that a 10Mbs ethernet connection would be
saturated with email (as you reported), to a one-person domain, and that
this volume not be abuse.

Its a common pattern of mailbombing.  

>   Your position is based on something called "faith", not "reality".

I think your position is based on something called "willful exaggeration" 
and its a well documented problem amoung anti-spam zealots.

I know some of the "experts" that looked at your abuse, and they have been
known previously to be anti-spam zealots, one of which is known to
conducted (or supported) abuse of our relays.

		--Dean

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 07 Jun 2005 14:27:36 -0400

Dean Anderson <[email-masked]> wrote:
> saturated with email (as you reported)

  My machine has never had had a 10Mbs connection to the net.

> to a one-person domain, and that this volume not be abuse.

  You're assuming that the people buying the "100 million email" spam
CD's know it's a one-person domain.

> I think your position is based on something called "willful exaggeration" 

  <grins>  You haven't seen the data, so I must be exaggerating.

> conducted (or supported) abuse of our relays.

  I've never made that list public, and to the best of my knowledge,
neither have they.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 07 Jun 2005 14:29:02 -0400

> Lets try non-fallacy arguments.

  Where in the question you quoted did I mention SPF?  I've looked,
and for the life of me, I can't find it.

  Alan DeKok.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 7 Jun 2005 18:22:06 -0400 (EDT)

>   My machine has never had had a 10Mbs connection to the net.

Your attempts at being coy are rather unbecoming.  Please be honest. You
rported on freeradius that your machine used to have colo'd ethernet
connection. You reported on freeradius that your colo ISP asked you to
find service elsewhere because of your spam volume was saturating the
ethernet.  [BTW, that alone should tell you that it isn't "normal" spam
volume]

> CD's know it's a one-person domain.

The addresses have to find their way onto such cd's.  If you start getting
mail like you have a million subscribers, then probably something is
wrong, because that doesn't usually happen.  The cd creators would seem to
have no interest in putting fake addresses on the CD. [They would plainly
have interest in harvesting addresses, but that doesn't usually result in
thousands or millions of fake recipient addresses to a one person domain]
So either someone must have somehow fooled them into thinking you have
millions of subscribers, or perhaps _they_ have something against you. 

But you (and your "experts") are the _only_ case of a one-person domain
that I've ever heard of, that gets this much email and subsequently argues
that it was somehow "normal".

What I _suspect_ is that one of the following is the truth: 
	you were either playing with harvesting, and got burned, 
	or someone else was playing with harvesting to burn you,
	or someone used a list of open relays or proxies to mailbomb you.

What I _know_ [from your posted statistics and reported info] is that it
was not an ordinary sort of spam load, as you (and your "experts") have
claimed.  And I _know_ that some of your "experts" were either involved
with, or at least supportive of those who abused open relays.

Further, as I recall, it stopped eventually, and was intermittent.

>   <grins>  You haven't seen the data, so I must be exaggerating.

I have some of the statistics, so yes. it is quite possible to draw
conclusions without the raw data. [that is why they call it data
reduction] Unless, of course, you lied in the statistics you reported.  
But if you want to send me the raw data, I'll still take a look... You
shared it with others, and it is all yours, so its up to you.

This isn't the first time for such a statisical surprise.  Operators have
previously been surprised before what can be inferred with indirect,
remote telemetry and statistics.  The distance to a star, for example.  
And no one has ever seen an atom, either.  All surprises.

Indeed, A certain network operator I know (Nathan Mehl) is _still_ stunned
about an incident that happened way back in _1994_, where I determined his
news server was overloaded by looking at the times on packets.  He had
first denied it was overloaded, and blamed the problem on our connection.
He was quite stunned when I showed him statistics on the connection and
timings on the news packets that indicated his server was overloaded. Only
then did he finally admit that it was overloaded. And others were also
complaining about their servers being overloaded.  The problem was solved
by adding additional new server.  [though he leaves that final admission
out of his recent retellings, I have most of the email from 1994, as well
as the load statistics. Tapes of home directories are indeed wonderful
devices, and properly stored, hold data for a long time.

[BTW this will go up on www.iadl.org sometime as an example of selective
memory vs defamation:  Nathan Mehl was the engineer at BBN Planet. I think
it will go under the section on Chris Neill, it compares and contrasts
with Chris: Nathan can be somewhat forgiven for misremembering facts from
1994 many years later. In contrast, Chris was reporting right after the
event. But neither admits being wrong. [anti-spammers never admit being
wrong even conducting abuse like mailbombing] To summarize:  Chris Neill
was a abuse admin with Verio who abused our relays from his desktop. He
was finally fired for this. He wasn't the only abuse admin fired for
abuse, but so far as I know, he is the only one who posted a diatribe
describing what happened to a public mailing list. But like many, rather
than accept responsibility for doing a "bad thing", he blames others (me)
for reporting his abuse. They never "remember" being wrong.  And indeed,
no anti-spammer has ever rebuked him for his abuse.  Most are sympathetic:
Abuse is OK, so long as its "for the cause". Anti-spammer generated junk
mail is euphemistically called "mailbombing"]

>   I've never made that list public, and to the best of my knowledge,

I'm sure I don't have the _entire_ list.  But Chris Parker of
Starnet/Megapop and company seem to be among the ones who said I was wrong
on freeradius.  Our relays were subsequently abused by hundreds of IPs
from Starnet, and when I complained, Parker indicated that he would not
act on our complaints because he didn't consider open relay abuse to be
abuse. [which is actually consistent with what he told you about your
incident] It shows their support for abuse.  I think we had to block port
25 from all of starnet's blocks.  [And in 2003, when the open relay
blacklists shutdown, open relay abuse also stopped. It restarted in March
of this, but very, very lamely.]

		--Dean

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 07 Jun 2005 18:30:26 -0400

Dean Anderson <[email-masked]> wrote:
> You rported on freeradius that your machine used to have colo'd
> ethernet connection. You reported on freeradius that your colo ISP
> asked you to find service elsewhere because of your spam volume was
> saturating the ethernet.

  You recall incorrectly.

> that it was somehow "normal".

  I've never said it was "normal".

> claimed.

  I've never said it was ordinary, and neither have any experts I've
talked to.  The description I recall is "Holy f*ck!".

> Further, as I recall, it stopped eventually, and was intermittent.

  You recall incorrectly.  It was never intermittent, and it hasn't
stopped.

> [Re: list of anti-spam people who've seen data from my domain ]
> 
> on freeradius.

  Chris Parker has never analyzed spam for my domain.

  This is fun!  Let's do it again.

  Alan DeKok.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 7 Jun 2005 19:02:13 -0400 (EDT)

> and for the life of me, I can't find it.

Maybe you missed the title: Re: draft-schlitt-spf-classic-01.txt

---

From: Dean Anderson <[email-masked]>
Date: Tue, 7 Jun 2005 19:01:47 -0400 (EDT)

>   How do you know the mind of the spammers?  Are you in contact with them?

How do economists figure out the purposes and principles of business?  
Observation and analysis.  It doesn't take rocket science to figure it
out.

http://www.av8.net/SpamTypes.txt

Your spam isn't type 1. It isn't type 2. Wait, Type 3 seems to fit pretty
well.

Type 1 Commercial spammers have anonymous .be or .nu domains, which
prevent return mailbombing. Or they use their own domain.  They don't need
to forge your address in the "From:" field.  They want you to buy their
product.  They comply with CAN-SPAM and don't forge addresses.

Type 2 Fraudsters want people to respond so they can conduct the fraud.  
They don't need to forge your address, that would hurt the fraud. They
send out messages, hoping for response. The from address is real. It may
be stolen, but its real, until, perhaps it is turned off in response.

Type 3 abusers are trying to conduct some type of annoyance or extortion
or infection. They want you to get hate mail, they want to annoy you. Or
they want to infect people you know with viruses.  They want people to
think the mail came from you or at least from your domain. That is the
point.  They can't comply with CAN-SPAM, as they aren't real businesses.  
This distinguishes pure abusers from commercial bulk emailers, which is
what the DMA set out to do with CAN-SPAM.  And CAN-SPAM has been
very successful at demonstrating that.  

		--Dean

[and yes, I'm aware that many anti-spammers think that CAN-SPAM has been a
dismal failure. And it has certainly been a blow to their claims and their
world view.  But its been a success for the DMA. The anti-spammers were
wrong when they rejected the IEMCC proposal in 1997. Probably, it is
anti-spammers that are generating much of the type 3 abuse---anti-spammers
were generating the open relay abuse, and that was very similar in
characteristic to the current type 3 abuse.]

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 07 Jun 2005 19:24:53 -0400

> mailbox destination.  Often you can not know this path, nor would you

  But if I deliver a message to the MX that is authoritative for the
domain of the mailbox, the message is *delivered*.  It's *done*.
You're assuming that *my* message gets forwarded *from* the domain I
sent it to, and that it's still marked as *my* message.

  If it does, I don't see why it's labelled as "my" message.  The
historical approach to label it that way is nice historically, but
there appear to be some kind of abuse issues associated with it...

> SPF somehow magically protects them.  A shamefully false statement of

  Sure.  But if they choose to accept that accountability, isn't that
their choice?

> The suggested dummy PRA record by Sender-ID has already been
> declared to have limited value in the future.  What then?

  They can use a proposal that doesn't have problems.

> to ensure the domain owner's protection in the all to common case of

  That's a matter for the documentation of the proposal, not for it's
implementation.

> indicates what is being assured by the domain owner.

  Of course.  Any similar system should have similar assurances.

  Alan DeKok.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 03:18:16 +0200

Alan DeKok wrote:

> if I deliver a message to the MX that is authoritative for
> the domain of the mailbox, the message is *delivered*.  It's
> *done*.

"Final delivery" is something different, I'd say "sent" where
you say "delivered".

> You're assuming that *my* message gets forwarded *from* the
> domain I sent it to, and that it's still marked as *my*
> message.

There's no problem, the MX can be a gateway to some fascinating
UUCP forwarding, or forward your mail to an MDA, with several
hops, it's all fine and still MAIL FROM you RCPT TO recipient.

> If it does, I don't see why it's labelled as "my" message.

Here you're talking about a _new_ recipient with _another_ MX.

That's of course not more your responsibility, and if there is
a technical problem it's definitely not your problem.  As soon
as another MX of a third party is involved it's the problem of
the "original" recipient.  He could adjust the MAIL FROM - one
of the many ways to deal with his responsibility.

> The historical approach to label it that way is nice
> historically

It is _not_ the historical approach, that's only a legend of
the "bounces-to" camp.  Historically each forwarding host added
its name to the reverse path, MAIL FROM @mx3,@mx2,@mx1:you

For obvious reasons that design worked against forged addresses,
mx2 and mx1 were not interested to forward any MAIL FROM you if
they would have to deal with later bounces to you.

That's also the reason why there's a 551 "user not local" code.

When they killed the source routes in 1123 they simply "forgot"
that this is a security loophole for the 251 alias-style of
forwarding - RfC 1123 is 16 years old, nobody could foresee the
disastrous effects of this security loophole in SMTP today.

But when you said (in your LMAP memo) that some LMAP proposals
_change_ the original _semantics_ of the MAIL FROM this is NOT,
repeat NOT, repeat NOT, true.

The MAIL FROM _semantics_ is as it always was since STD 10.  And
SPF simply uses it to fix this security loophole in SMTP today,
for those who want it.

> if they choose to accept that accountability, isn't that
> their choice?

Of course.                 Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 08 Jun 2005 03:39:42 +0200

> Who is really most deserving of this eloquent message?

The verbose variant wasn't suited for a mailing list open
for the public includinng children.

> http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

When you say that PRA is incompatible with v=spf1 policies
you're right.  That is _old_ news, see also Meng's article:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/8119>

Or Wayne's comment about it:
<http://article.gmane.org/gmane.mail.spam.spf.discuss/8162>

> You are ignoring a reality that Microsoft has usurped the
> definition of the v=spf1 record and clearly has this record
> in their pocket.

This is not the case.  See below what I'e written to two IESG
members, as far as I'm concerned everybody can read it.  Some
days old, the new draft is now -02 and not more -01, bye, Frank

[does draft-lyon-senderid-core-00 obsolete SPF version 1 ?]

No, it is only trying to use several hundred thousands published
v=spf1 policies for the similar spf2.0 scheme.  These schemes are
partially incompatible.  The PRA is not necessarily related to the
MAIL FROm, that's why MARID first decided to introduce spf2.0/pra,
later adding spf2.0/mfrom - the latter is compatible with v=spf1.

After MARID was closed the SPF community resumed its work on v=spf1,
resulting in the drafts from Mark Lentczner and later Wayne Schlitt.

The Schlitt drafts clearly say that testing v=spf1 policies with
something they were never designed for (like the PRA algorithm) is
NOT RECOMMENDED.  It can result in loss of legit mail.  This issue
has been discussed on many lists (spf-discuss, MARID, IETF general,
etc.).

The new Schlitt draft -01 (published yesterday) explains the issue
with the NOT RECOMMENDED better.  The new wording should make it
clear that of course using the PRA algorithm with any spf2.0/pra
policy is no problem - actually almost nobody in the SPF community
cares about the PRA.  But using PRA with v=spf1 will cause havoc.

I'm surprised why there was a note to the RfC editor proposing to
remove the old NOT RECOMMENDED from the old Schlitt draft -00,
while there was no note to remove the SHOULD from draft Lyon -00:

| SHOULD interpret the version prefix "v=spf1" as equivalent to
| "spf2.0/mfrom,pra"

This is plain wrong.  No v=spf1 policy was designed to survive a
PRA test.  Many v=spf1 policies were published long before MARID,
when Sender-ID was still Caller-ID.  A v=spf1 policy is _almost_
equivalent to spf2.0/mfrom (the latter has no HELO check, but it
checks MAIL FROM), but it is incompatible with spf2.0/pra.  The
new draft Lyon -01 still has the same serious technical problem.

                             Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 07 Jun 2005 18:55:17 -0700

On Tue, 2005-06-07 at 19:24 -0400, Alan DeKok wrote:
>   If it does, I don't see why it's labeled as "my" message.  The

Assume you sent a message to a simple exploding list for example.  While
you could conclude that once the list server accepted your message, it
now becomes the list server's message.  From a reputation standpoint,
this is not desirable from the perspective of the list operator, who
would like any abuse to directly impact those they see as accountable.

The abuse that concerns you has to do with how the accountable entity is
determined.  If the accountable entity is determined by some
mailbox-domain having authorized a sending server, then indeed this can
lead to failure or abuse, especially when many domains authorize the
same sending servers.  On the other hand, if the accountable entity is
determined by validating a signature using a key published by the
sending domain, then any opportunity for this to be abused is
dramatically reduced.

Assume you send a message to a forwarding account that acts as an alias
for the recipient.  You consider the message being forwarded, by having
the recipient altered on the envelope, to be technically a modified
version of your message.  Nevertheless, the content of your message
remains unaltered.  Where a delivery failure notice must be sent also
remains unchanged to provide the eventual recipient this essential
information.

It makes no sense to alter the information that normally gets forwarded
to satisfy a flawed scheme that infers the source of a message through
server authorization.  This is where abuse may occur, as
server-authorization being considered equivalent to
sender-authentication is a scheme that unfairly makes assumptions of
origin.

I see no problem having high thresholds on the HELO or IP address of the
sending server to form a basis for network protection.  I see no problem
allowing forwarding or list servers (leaving mail unaltered), and
relying upon signature validation to determine accountable entities as a
basis for recipient protection.  However, there is no reasonable method
to base accountability of a message upon the server having been
authorized.

>   Sure.  But if they choose to accept that accountability, isn't that

In the many presentations I have attended, I have yet to hear any
warnings that by publishing an SPF record, the domain owner's reputation
may become damaged beyond their control, regardless of the type of list
published.  I have not heard anything beyond a warning there may be some
reputation risk related to publishing an "open-ended" list.  Seldom is
this explained to mean either risk some messages being lost when
forwarded in some fashion, or risk readily obtaining a bad reputation.
Of course, even a "close-ended" list can not offer substantial
protection from forgery when the MTA is shared.

>   They can use a proposal that doesn't have problems.

Which proposal is that?  It is not draft-schlitt-spf-classic-01, or
draft-lyon-senderid-core-01.  These two drafts are in serious conflict,
and the Sender-ID draft claims that server authorization is equivalent
to sender authentication, whether for the bounce-address or the PRA.  Do
you really think it is safe to ignore the intentions of Microsoft?

>   That's a matter for the documentation of the proposal, not for it's

I hope they consider the outcome of having withheld this information.
Class-actions love deep pockets.  : )

>   Of course.  Any similar system should have similar assurances.

Even by obtaining the record's scope, SPF/Sender-ID assumes email
providers are perfect at assuring exclusive use of a mailbox-domain
within this scope.  Have you seen any indemnification making this claim?
This scheme is filled with assumptions and false assurances.  If you do
not run your own MTA and can assure exclusive access, SPF/Sender-ID is
an extremely risky choice.  Unless you are willing to have some messages
go missing, SPF/Sender-ID is an extremely risky choice.

The safer choice is DomainKeys upgraded to DKIM. : )

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 08 Jun 2005 17:39:30 -0400

> "Final delivery" is something different, I'd say "sent" where

  Which is part of the confusion.  The Simple Mail Transport Protocol
transported the message from origin to destination.  That's
"delivery", by at least one standard.

  When a FedEx guy hands my receptionist a package, he's "delivered"
it, for all intents and purposes.  The receptionist may, in turn,
deliver it to me, but that's a different kind of delivery.

  Much of the confusion around these discussions has been a result of
the terms being overloaded, and the participants not qualifying the
context in which they use the terms.

> hops, it's all fine and still MAIL FROM you RCPT TO recipient.

  Once the MX for your domain gets the message, any final steps to get
it to your physical mailbox is *internal* to your site.  It varies
from site to site in a way that SMTP does not.

> the "bounces-to" camp.

  <shrug>  For me, it's all "he said, she said".

> SPF simply uses it to fix this security loophole in SMTP today,

  And there's the sticking point: "those who want it".

  It's about consent.  Two adults consenting to do stupid things is
not something anyone can control or prevent.  Yet there's been
significant effort in the SMTP community to do just that.

  Alan DeKok.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 09 Jun 2005 12:13:13 +0200

Alan DeKok wrote:

> Much of the confusion around these discussions has been a
> result of the terms being overloaded, and the participants
> not qualifying the context in which they use the terms.

Yes, but in essence it's still "simple", and claims that SPF
"breaks forwarding" are an over-simplification, like your
statement "when the MX has the mail it's delivered".

My point is that it can be "forwarded" behind this MX without
"breaking".  Only in one special case the receiver would be
in trouble, if he arranges his "delivery" in a way including
an SPF-test behind the first MX.

> Once the MX for your domain gets the message, any final steps
> to get it to your physical mailbox is *internal* to your site

Even in that simple and normal case I have a chance to get it
wrong, secondary MX forwards to primary MX, primary MX tests
SPF, FAIL => your sender policy does of course not permit the
IP of my secondary MX, I forgot to white list this beast.

That's not necessarily "internal", but it's certainly my fault.
You'll get a bounce, and maybe you inform my postmaster@ that I
screwed up.  No real problem, shit happens, I'd simply fix it.

BTW, in practice I had this problem only once since April 2004,
apparently receivers testing SPF normally get it right.  After
all it's no rocket science, "test a.s.a.p. or don't test it".

>  <shrug>  For me, it's all "he said, she said".

The "he" was Jon Postel in STD 10, the "she" are later texts.
And "her" claim is that "MAIL FROM" was an error and actually
means "BOUNCES TO" - "history" as you find it in Orwell's 1984.

>> The MAIL FROM _semantics_ is as it always was since STD 10.
>> And SPF simply uses it to fix this security loophole in SMTP
>> today, for those who want it.

> It's about consent.  Two adults consenting to do stupid
> things is not something anyone can control or prevent.  Yet
> there's been significant effort in the SMTP community to do
> just that.

"Philosophical discussions" about design flaws 16 years after
the fact are difficult - with Wayne's time machine I wouldn't
go back to 2003, but jump directly on the desktop of the 1123
editors.  With a loaded gun... ;-)
                                   Bye, Frank

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 09 Jun 2005 13:30:44 -0400

Frank Ellermann <[email-masked]> wrote:
> That's not necessarily "internal",

  It's internal to the trust boundary of your domain.  I have no way
of knowing that it's a secondary, and you do.

> editors.  With a loaded gun... ;-)

  The purpose of philosophical discussions are to obtain a common
agreement as to the intent of the system.  If no one can agree on
*why* the system exists, or *what* it's supposed to be doing, then
talking about *how* is a waste of time.

  But the discussions I've seen have focussed on "how", and have
steadfastly avoided the "why".  The existence proof of the email
system is nice, but a collection of patches over time can result in a
system that no one intended to build.  Proof: the spam problem.
  
  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 09 Jun 2005 15:51:51 -0400

Douglas Otis <[email-masked]> wrote:
> now becomes the list server's message.

  I think the word we're missing here is "anthology".  Anthologies are
collections of copyrighted works by individual authors, along with an
editor who has a "collection copyright" on the sum total of the work.

  One email message, therefore, is an anthology with multiple authors.
One person wrote the text, another person wrote the quoted text (if
any), the mailer wrote some of the headers (message-id, etc), and so
on.  Reputation for the collected work impacts all of the authors in
that collection, to varying degrees.

> From a reputation standpoint, this is not desirable from the
> perspective of the list operator, who would like any abuse to
> directly impact those they see as accountable.

  If I send a copy of a DVD to this list, and this list re-distributes
it, the list owner may be responsible for "contributoy infringement".
Reputation affects both me as author of the message, and the list
owner as distributor.

  If we were to require that list owners *not* have their reputation
affected by messages they re-send, then spammers can hide behind lists.

> determined.

  s/entity/entities/

  That's really the crux of my argument.

> you really think it is safe to ignore the intentions of Microsoft?

  Nope.  And if all of the proposals re so terrible, we should see if
we can come up with another proposal that isn't so bad.

  Alan DeKok.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 02:23:12 +0200

Alan DeKok wrote:

> It's internal to the trust boundary of your domain.

Yes, in that sense it's "internal" from your POV.
 
> The purpose of philosophical discussions are to obtain a
> common agreement as to the intent of the system.  If no
> one can agree on *why* the system exists, or *what* it's
> supposed to be doing, then talking about *how* is a waste
> of time.

It's a bit like Euclidian geometry (maybe s/Euclid/Postel/)
- and the bounces-to universe is the non-Euclidian geometry.

You can't say that non-Euclidian geometry is "wrong".  It's
perfect, parallel lines cross each other, MAIL FROM actually
means BOUNCES TO, the sum of degrees in a triangle isn't 180,
and the responsible party is not the Return-Path, but hey,
how about fixing it with a PRA ?
                                 Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 09 Jun 2005 17:45:50 -0700

On Thu, 2005-06-09 at 15:51 -0400, Alan DeKok wrote:
> it, the list owner may be responsible for "contributory infringement".

This would be a valid concern.  On the other hand, if the original
sender could be authenticated, and there was some breach of conduct,
then seeking redress from this original sender would provide a fair
method to deal with such offenses, without directly impacting the list
server.  This would also assume the list server would disable access
when warranted.  Authentication of the original sender would also
inhibit spoofed messages from invoking errant retribution.

>   Nope.  And if all of the proposals are so terrible, we should see if

I see DomainKeys, soon upgrade to DKIM, as a step in the right
direction.  Until I see the details regarding DKIM, I am unable to
comment what remains to be done.  I will speculate there is a need to
introduce a somewhat independent layer of network resource protection in
addition to a signature scheme.  This will be especially important in
areas where network connectivity is limited.  It is yet to be seen
whether signatures, by themselves, will be enough of a deterrent.  My
fear is when they become more effective following wide spread adoption,
signatures will need to be aggressively defended.

-Doug