Subject: Re: [Asrg] How about we do something about spam?

From: Douglas Otis <[email-masked]>
Date: Wed, 31 Jan 2007 23:10:37 -0800

On Wed, 2007-01-31 at 21:54 -0500, Barry Shein wrote:

> You seem to prefer a technological solution, possibly with some new
> legislation making "spam" illegal. I have no particular problem with
> that, in spirit.

DKIM, together with autonomous associations, can be used to prevent
spoofing and allow opportunistic security in a fashion similar to SSH.
The recipients should first confirm sources using an out-of-band
technique, such as a picture or pass-phrase included within an
introduction.

DKIM can identify the entity transmitting the messages when used
properly.  Unfortunately, providers do not want to identify themselves.
Prompt relief from abuse requires that transmitters identify themselves,
and NOT their customers.  Their customers can offer domain associations
as authorization when needed.

> But I do believe that a more immediate goal of urging law enforcement
> (et al) to better enforce existing laws (&c) regarding the creation
> and operation of, e.g., zombie botnets is valuable without in any way
> detracting from other efforts stated.

Why focus on Bot-Nets?  Microsoft's PNRP protocol coupled with Teredo
(RFC4380) named after teredo navalis, Latin name of a common species of
shipworm, provides a loosely coupled matrix of computers exchanging
complex addresses designed to penetrate compatible firewalls and NATs.
Every game manufacturer will have kids playing interactively within
structures closely resembling malware created Bot-Nets now sans
reference to DNS. There will not be much luck trying to police this type
of traffic. 

> Put another way, we don't board up all our windows and let burglars
> run free. We try to make burglary dangerous for burglars.

There are many gated communities that control access, where individuals
are not free to test every door or window without being noticed.  The
CAN-SPAM law prevents a practical means to limit access, or to call
authorities when such control is challenged.  There is no sure means to
know when a message is safe, but limiting the number of attempts offers
significant protection in itself.

The best strategy is to limit the spread of infection.  This means
people MUST NOT be allowed to bulk send unsolicited messages.  The
CAN-SPAM act allows spammers a simple strategy of switching to a
different product line after 10 days, once someone has requested them to
stop.  You can't even expect spammers to offer their physical address
when most messages from Fortune 1000 or even Senators ignore this
requirement.  They expect you to follow a link.  Even attempting to
OPT-OUT often attracts additional traffic.

Providers must control access, block abusers, and be held accountable
when they fail to do so.  When someone spams, they must be blocked.
Sending volumes of unsolicited messages is rather easy to detect, where
miscreants can be blocked quickly.  When this traffic is from customers
using compromised systems, then each problematic customer's outbound
messages must be blocked.

Of course, the next concern might be malware placed in websites, even
things like Wikipedia might contain malware.  There must be efforts made
to ensure blogs are properly defanged as well.

There are laws against spyware, but knowing when information has been
compromised is extremely difficult.  Establish an agency that handles
SSNs changed into something that looks like a credit card number.  Allow
each company to ask for a stable reference of the individual that is
unique to the requestor.  Allow a citizen to report that they suspect
their information may have been compromised, and have it changed at no
charge.  Any requestor asking for a stable reference of a invalidated
number should attract attention.

The agency would need to provide services that allow companies to
exchange their stable references, but never the original numbers.
Sharing original numbers are too likely to be detected as having been
invalidated and leading to an investigation.  There might even be
significant fines related to requests with invalidated numbers.

-Doug

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Feb 2007 17:08:36 +0100

> This would place accountability onto the provider.  The efforts
> behind SPF and DKIM are aimed at passing blame to a hapless customer.

Nonsense.  SPF FAIL protects HELO identities and envelope-sender
addresses, SPF PASS guarantees that bounces cannot hit innocent
bystanders.  And DKIM allows signers to take the responsibility
for a mail transmission independent of SMTP.

> Thousand of domains might share an SPF authorized server which
> is likely to have only a few IP addresses.

Therefore only a few IPs are permitted to use the domain as HELO
or in an envelope-sender.  Implementing RFC 4409 ("submit") and
2554bis ("auth") on that shared server is an obvious next step,
SPF explicitly recommends this.  FWIW, not much yet, publishers
of sender policies can even state (= claim) that their server(s)
don't allow "cross-user-forgery".

Won't help them if they manage to become a part of a botnet, but
as expected SPF and/or DKIM are no FUSSP.

> The identity limitations with DKIM ensures providers will also
> control their customer's private keys.  Who sent and signed the
> message is _designed_ to remain a mystery.

 [I-D.ietf-dkim-base-07 chapter 6.3]
| If the message is signed on behalf of any address other than
| that in the From:  header field, the mail system SHOULD take
| pains to ensure that the actual signing identity is clear to
| the reader.

> There should be laws against the use of highly danger
> authorization schemes, such as SPF/Sender-ID.

Omigod - how about a law against those dangerous MX records ?
Without MX records the spammers won't know where to they could
send their crap.  Highly dangerous, this MX.  Without it we'd
have RFC 821 source routing again, SPF would be unnecessary. :-|

> Enforcement must make any spam illegal AND hold providers
> accountable.  To ensure enforcement, allow anyone damaged to
> seek legal relief.

Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue.
Is that a new all-time low in the history of the IRTF-ASRG ?

> The volume and lack of solicitation provides key differences.
> The lack of solicitation allows for rather easy methods of
> enforcement.

RFC 3865 is already published, check it out.

> OPT-OUT is a dangerous, impractical, and an immoral excuse.

At least we agree on something.

>> It takes a zombie botnet.

> There are many other techniques.

Open proxies and open relays.  If that's all it's not "many".

F

---

From: Dan Oetting <[email-masked]>
Date: Thu, 1 Feb 2007 10:14:52 -0700

> detracting from other efforts stated.

Technical solutions can coexist with law enforcement options. I just  
stumbled on the site running Project Honeypot <http:// 
www.projecthoneypot.org/about_us.php> that is analyzing data from web  
scrapers and spambots to help put together the case evidence for  
spammers harvesting addresses from web pages which is also a  
violation of existing laws (according to the site).

I was pushing for distributed collection of spamtrap data about 2.5  
years ago. The primary goal was (is) to develop a fast blocklist to  
shutdown the spambots that were just emerging. I was told this idea  
was FUSSP directly by the inventor of the term and that it would  
never work. In my research last night I also found <http:// 
research.ciphertrust.com/index.php> that in part is doing precisely  
what I was proposing. I've grown to mistrust anti-spam expert and  
tend to think their primary goal is to enhance their worth by  
insuring the fight against spam continues.

After looking at some of my own posts from 2.5 years ago I could see  
how far we've progressed. Back then I was able to manually process  
all the spam that hit my inbox (with no pre-filtering by the ISP).  
Today I can barley scan the titles of the spam I get and I know there  
is lost legitimate mail due to the upstream filters.

I'm still pushing my idea because I still believe it can help reverse  
the current trend of more and more spam every year. Even though there  
is apparently a commercial implementation, the goals of [2.3.5.   
Avoid central administration] and [2.3.6.  Don't impose commercial  
administration] can be better realized in a public system. I'm also  
not one that blindly sticks to an idea. I am more of a scientist and  
would be just as interested in how the idea fails as in seeing it  
succeed. But I'll demand to see data before changing my mind.

-- Dan Oetting

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Feb 2007 09:26:09 -0800

I don't even know where to start about the mischaracterization of dkim
here, so I won't. Suffice it to say that Doug's take on dkim is nu^H^Hpretty
idiosyncratic.

Douglas Otis wrote:
>
> On Jan 31, 2007, at 3:32 PM, Barry Shein wrote:
>
>>
>> On January 31, 2007 at 21:52 [email-masked] (John Levine) wrote:
>>>> Some confirmation from respected sources might help.
>>>
>>> Well, at this moment, I am sitting in a session at MAAWG where the 
>>> FTC's lead spam investigator is telling us about his investigation 
>>> process and he and ISP reps are going over issues like whether they 
>>> notify customers when they get a subpoena.  Also present are the 
>>> Canadian competition bureau, analogous to the FTC, and I believe I 
>>> saw some guys from DOJ.
>>
>> Well that's of course great but some publicized thrust and focus from 
>> the IETF couldn't hurt the thinking of the policymakers who have to 
>> actually allocate budgets and other priorities.
>>
>> Is there any disagreement that if we could just snap our fingers and 
>> make the zombie botnets disappear (or 90% disappear) that "spam" (and 
>> related) wouldn't immediately have all the emotional punch of 
>> "off-topic posting", some odd msg you get and delete?
>>
>> Put another way, zombie botnets are the enabling technology of spam 
>> (phishing, etc.)
>
> Put another way, legalizing spam enables high infection rates needed 
> to support the existence of Bot-Nets.  Malware content within an email 
> message and websites (required to OPT-OUT) provide bad actors ample 
> opportunity to leverage exploits that exist in email or website 
> browsers.  The completely absurd stipulations of OPT-OUT is satisfied 
> by a link to a web site of all things.  CAN-SPAM mandates victims 
> expose themselves to two very likely modes of infection.  Browsers 
> continuously have new and complex features added, where many flaws 
> exist and can be exploited.  Bulk messaging with embedded links 
> provides a highly dangerous infection vector.
>
>> Easier said than done I realize, but it's inherently illegal to 
>> create and operate zombie botnets, and I don't mean just in the US, 
>> most anywhere on the planet.
>
> By making spam illegal, the act of transmitting a high volume of 
> unsolicited messages would then clearly serve as evidence of crime.  
> This would place accountability onto the provider.  The efforts behind 
> SPF and DKIM are aimed at passing blame to a hapless customer.  
> Thousand of domains might share an SPF authorized server which is 
> likely to have only a few IP addresses.  The identity limitations with 
> DKIM ensures providers will also control their customer's private 
> keys.  Who sent and signed the message is _designed_ to remain a 
> mystery.  Some mode of accountability.
>
>> The law enforcement and regulatory agencies of the planet have a lot 
>> more resources they can muster than we ever could.
>
> Providers must acknowledge they are primarily responsible for much of 
> the mess that exists.  Providers must be held accountable when any 
> high volume of unsolicited messaging emerges from their networks.
>
>> Even if we could come up with the FUSSP we'd still probably face 
>> enormous hurdles of deployment.
>
> The first step would be to make spam illegal.  Illegal for individuals 
> to send, and for providers to ignore.  After all, providers control 
> access.  Allow those damaged to seek relief.  Making spam illegal 
> would make networks many orders of magnitude safer.
>
>> Vigorous legal pursuit wouldn't preclude technical efforts in 
>> parallel unless of course spam just disappears as a result.
>
> Twice the technological effort is attempting to pass blame to some 
> likely hapless customer.  Make a law that requires providers sign all 
> public messages with their own keys.  There should even be laws that 
> prohibit signing with a customer's key.  Customers can reference 
> specific keys used on their behalf instead.  There should be laws 
> against the use of highly danger authorization schemes, such as 
> SPF/Sender-ID.  Poisoning or destroying DNS is easily accomplish with 
> this loathsome technology.  A technology also aimed at side stepping 
> accountability.
>
>> There is no other way we know of to send out on the order of one 
>> billion emails per day for a cost which even approaches the expected 
>> value of those messages and would so successfully evade already 
>> commonplace blocking and filtering methods.
>>
>> Does anyone disagree with that?
>
> accountable.  To ensure enforcement, allow anyone damaged to seek 
> legal relief.
>
>> Can't we say that in some very public way? Does anyone doubt that's 
>> true?
>
> There are few providers that want to consider their accountability as 
> part of the cost of doing business.  No one can afford to clean up the 
> mess being made.  Just as was done to control the abuse of fax 
> machines, the same must be done with respect to email.  At least with 
> a fax machine, programs were not in jeopardy, just resources.
>
>> Sometimes I think the problem otherwise insightful technical people 
>> have in thinking about spam is wrapping their heads around what it 
>> takes to send out O(billion) messages a day from a handful of base 
>> sources and we keep retreating to imagining spam as being much like 
>> sending this message other than the content and intent.
>>
>> It's not.
>
> Content or intent do not need to be considered.  The volume and lack 
> of solicitation provides key differences.  The lack of solicitation 
> allows for rather easy methods of enforcement.  One grows weary 
> logging trespasses that can only be considered privately as bad.  
> Those making these private assessments remain exposed to civil 
> proceeding as a result.  Spam must be illegal to stop it.  There are 
> very few legitimate businesses using spam to promote their products, 
> and yet the US Congress has legalized spam.  OPT-OUT is a dangerous, 
> impractical, and an immoral excuse.
>
>> It's as if I could make this message appear in 100 million mailboxes 
>> in the next few hours, despite many efforts to the contrary.
>
> The number of messages does not matter.  The number of unsolicited 
> messages does.
>
>> I couldn't. You couldn't.
>
> Not true.  There are some rather large mailing lists where such 
> volumes are possible.  Lists enjoying a large number of subscribers 
> are also typically well managed.
>
> There are many other techniques.  Malware provides many avenues to 
> exploit networks.  Make spam illegal to slow the spread of malware.
>
>> There are other issues, but I'm focusing on this one as the most 
>> egregious and, I hope, easiest to agree on in terms of contribution 
>> to the problem and legal/moral unambiguity.
>
> You seem to have the cart before the horse.  In addition to spam, 
> perhaps other rules could be considered regarding system scanning.  
> This again would require that providers take action to block access.  
> Vista comes equipped with what is likely an ideal command and control 
> system for controlling Bot armies.  The system must protect from the 
> spread of infection.  Prevention is worth a pound of cure.
>
> -Doug
>
>
>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Feb 2007 10:37:22 -0800

On Feb 1, 2007, at 8:08 AM, Frank Ellermann wrote:

> bystanders.  And DKIM allows signers to take the responsibility for  
> a mail transmission independent of SMTP.

SPF does not protect the HELO as checking is optional and can be that  
of any domain, as compared to domains within the message.  SPF does  
not prevent bounces sent to those that did not send the message  
without also reducing email's delivery integrity.  Few SPF records  
have settings that operate in this mode as a result.  DKIM is not  
about signer's taking responsibility in most cases.  The DKIM  
signature can be replayed.  Who signed and who replayed?  Who is  
accountable for stopping abuse?

>> likely to have only a few IP addresses.
>
> Therefore only a few IPs are permitted to use the domain as HELO or  
> in an envelope-sender.  Implementing RFC 4409 ("submit") and  
> 2554bis ("auth") on that shared server is an obvious next step, SPF  
> explicitly recommends this.  FWIW, not much yet, publishers of  
> sender policies can even state (= claim) that their server(s) don't  
> allow "cross-user-forgery".

An unlimited number of domains are allowed to use _any_ IP address to  
authorize their bounce address or any other originating domain within  
a message.

> Won't help them if they manage to become a part of a botnet, but as  
> expected SPF and/or DKIM are no FUSSP.

Expecting millions of recipients to pass the SMTP client IP address  
(perhaps as seen in the Received header), and various email domains  
to a script process that might then request hundreds of DNS  
transactions for each email-address being checked is a good way to  
poison DNS, cripple DNS, or take down any network.

> | pains to ensure that the actual signing identity is clear to

How can a reader be expected to recognize the From header field in  
the first place?  This assumes there is method that allows a mailing  
system to take "pains" of ensuring what the reader can visually  
recognize something.  Messages where the From/sign-domain do not  
match will be given a "special" folder?  This restriction will  
eventually require email-address domain owners to supply providers  
with their private keys.  In the end, look-alike and cousin domains  
will simply become more credible, and bad actors will have fun  
breaking into MTAs holding thousands of keys.

> Without MX records the spammers won't know where to they could send  
> their crap.  Highly dangerous, this MX.  Without it we'd have RFC  
> 821 source routing again, SPF would be unnecessary. :-|

SPF expects recipients to not only check an MX record, but to resolve  
the addresses for each target within an MX record and to do this ten  
times over.  Instead, verify the host of the SMTP client, and then  
check for domain associations using a single DNS transaction.  This  
would be far safer in comparison.  The difference is rather stark.   
The transmitting entity would be required to identify themselves  
first.  If there is a problem, they might be asked to make it stop.

> Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue.  Is  
> that a new all-time low in the history of the IRTF-ASRG ?

Spam must be made illegal.  There should be no need for RFC3865, or  
for legal provisions that say it is okay to spam provided your  
message has a link that allows opting-out of this line of products.

>> The volume and lack of solicitation provides key differences. The  
>> lack of solicitation allows for rather easy methods of enforcement.
>

And so?  There should be an international agreement that bulk sending  
of unsolicited messages is illegal.  Any network that permits this  
activity should be blocked.  Spam would end very quickly, and  
infections rates would decline.  This would required that providers  
and law makers take action however.   RFCs should be aimed at  
identifying who is _transmitting_ the messages first.  If a bank  
wants users to know which providers are sending their email, there  
can be a simple, small, and safe DNS transaction to indicate their  
authorization of the provider.

Providers should be prevented from using the keys of their  
customers.  The same strategy could be used based upon HELO  
verification as well, but of course, a signature would be much stronger.

> Open proxies and open relays.  If that's all it's not "many".

Unfortunately there are many more.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Feb 2007 14:53:30 -0800

On Feb 1, 2007, at 9:26 AM, Michael Thomas wrote:

> I don't even know where to start about the mischaracterization of  
> dkim here, so I won't. Suffice it to say that Doug's take on dkim  
> is pretty idiosyncratic.

When it comes to providers transmitting public messages and  
identifying themselves directly, this always seem to result in a  
different take.

http://www.spartacus.schoolnet.co.uk/USAnast3.jpg

Unless the entity transmitting the public message can be confirmed by  
the signature, it offers little value from the perspective of  
enforcement or of abating abuse.

When there are many signatures added to a message, which signature is  
related to the entity transmitting the message, and how can that  
signature be located?

Is it your view providers should obtain their customer's DKIM keys to  
sign on their behalf?

Is it your view that the From email-address header matching with the  
signing domain is something safely communicated to the recipient?

How does this deal with the common use of display names, look-alikes,  
or cousin domains?

How will this deal with EAI and multiple addresses within the From  
header?

False positive detection of phishing attempts can be prevented when  
the phished entity has authorized the signature.  The basis of trust  
can be anything, where there is no need for the From domain to match  
the signing-domain.  It is important for the signature to indicate on  
who's behalf it was added.  DKIM lacks this essential feature however.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 12 Feb 2007 05:03:44 +0100

Douglas Otis wrote:

> SPF does not protect the HELO as checking is optional

Please look up RFC 2119 OPTIONAL / MAY vs. RECOMMENDED / SHOULD.
For checkers trying to figure out an empty MAIL FROM:<> it was
always required to use the HELO identity.

And no, there are no SPF policies for domain literals, checkers
would report a result NONE in this and similar cases.

> SPF does not prevent bounces sent to those that did not send
> the message without also reducing email's delivery integrity.

That's not the case, "reject any FAIL at your border" is the
very idea of RMX (one of SPF's predecessors).

> Few SPF records have settings that operate in this mode as a
> result.

Folks are free to publish records only enumerating PASSing IPs,
if they can't or don't wish to decide what to do with the rest
of the world.  There are various scenarios where that can be a
good choice.  I leave your DKIM "ideas" for DKIM experts here.

> SPF expects recipients to not only check an MX record, but to
> resolve the addresses for each target within an MX record and
> to do this ten times over.

As far as the policy uses an mx mechanism, and there are 10 MXs.

In reality SPF is about _sending_ IPs, using the mx mechanism
is already unusual, because it's about MTAs _receiving_ mails
for the domain in question.  Using 10 MXs is far more unusual,
after all the name server for the domain would like to answer
a query=mx without TCP.  Ideally including the relevant IPs,
avoiding additional questions.

MTAs having trouble with query=mx would be also quite unusual.

> Instead, verify the host of the SMTP client

Yes, that's the first step, see above.

> then check for domain associations using a single DNS
> transaction.  This would be far safer in comparison.

That doesn't work for domains using more than one mail provider
to send their mails.  All my ISPs would ask me what I'm smoking
if I'd propose to "associate" their outbound MTAs with a domain
xyzzy.dnsalias.org or similar.

On the other hand I could in theory associate this domain with
their services using SPF include:first.isp.example (etc.)

For your idea it would be more straight forward to revive 821
reverse routes, but unfortunately that failed a giggle test.

> Spam must be made illegal.  There should be no need for RFC3865,
> or for legal provisions that say it is okay to spam provided your

A good part of the spam I get has opt-out links, nobody uses this.
It would be also hopeless to opt-out all local parts of a domain.
As you wrote later "opt-out" doesn't work.

> There should be an international agreement that bulk sending
> of unsolicited messages is illegal.

Until that exists and works I'm more interested in the technical
sides of the spam problem.  Or of "misdirected bounces" wrt SPF
and 2821bis.  IANAL and all.

> Spam would end very quickly, and infections rates would decline.

 From an IETF POV RFC 3865 offers anything that's needed for this
kind of legal FUSSP.

> RFCs should be aimed at identifying who is _transmitting_ the
> messages first.

If it's an SPF FAIL it wasn't xyzzy.claranet.de, problem solved
as far as I'm concerned.  Similar GMane where I post this message.

And if it's an SPF PASS it's either me, or a problem between me,
my ISP, and another user of this ISP (= none of your problems) -
they can add op=auth to their policy when they are ready for it.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Feb 2007 11:00:12 -0800

> always required to use the HELO identity.

Nothing prevents bad actors from including a throw-away domain within  
MAILFROM to bypass most HELO checks.  The recipient might also use  
Sender-ID procedures that ignore both HELO and even MAILFROM when a  
PRA has been confirmed.

> would report a result NONE in this and similar cases.

The DKIM-DOSP draft accommodates even IP literals with a "named  
reference" authorization scheme.  There should be a convention added  
to authorize domains below SMTP Client host-names.  For example, an  
SMTP client host-name "mx-01.example.com" should first induce a check  
for "example.com".

>> SPF does not prevent bounces sent to those that did not send the  
>> message without also reducing email's delivery integrity.
>
> That's not the case, "reject any FAIL at your border" is the very  
> idea of RMX (one of SPF's predecessors).

When messages can not be delivered to forwarded accounts, that might  
be seen as reducing email's delivery integrity.  When there is a  
possible risk that a PRA provides acceptance, and then MAILFROM  
qualifies DSNs, this might cause messages to vanish.

>> Few SPF records have settings that operate in this mode as a result.
>
> Folks are free to publish records only enumerating PASSing IPs, if  
> they can't or don't wish to decide what to do with the rest of the  
> world.  There are various scenarios where that can be a good  
> choice.  I leave your DKIM "ideas" for DKIM experts here.

Advocating use of SPF checking at email borders gives bad actors a  
resource free method for indirectly DDoS attacking any domain.

>> resolve the addresses for each target within an MX record and to  
>> do this ten times over.
>
> In reality SPF is about _sending_ IPs, using the mx mechanism is  
> already unusual, because it's about MTAs _receiving_ mails for the  
> domain in question.  Using 10 MXs is far more unusual, after all  
> the name server for the domain would like to answer a query=mx  
> without TCP.  Ideally including the relevant IPs, avoiding  
> additional questions.
>

Some domains approach the 10 MX RR limits.  The concept of including  
10 separate SPF records is not only due limitations in the TXT RR  
size, but that different domains might be employed.  Some SPF scripts  
default to an MX/24 answer and assume outbound systems are often  
numerically close to inbound systems.  While some MTA may confirm the  
existence of an MX RR, how many resolve all MTA target addresses, and  
then do this 10 times over?   SPF allows bad actors to embed this  
behavior for millions of emails sent by responding to just the  
initial DNS queries.  Once it becomes clear the spam will be sent  
anyway, SPF simply offers a virtually free method to stage a DDoS  
attack against any domain.

> Yes, that's the first step, see above.

Too bad this is optional, and encumbered with a DDoS risk when using  
SPF/Sender-ID.

> That doesn't work for domains using more than one mail provider to  
> send their mails.  All my ISPs would ask me what I'm smoking if I'd  
> propose to "associate" their outbound MTAs with a domain  

Actually a "named reference" works even when there are millions of  
different providers for an originating domain.  The provider does not  
offer the authorization for the originating domain.  These domains  
might be found anywhere within the message.  This might be the  
MAILFROM, From, Sender, Resent-*.  Each field could have a different  
"named reference" authorization.  Which authorization is checked  
depends upon which originator is being trusted.  To use DNS, the  
authorization is located within each originating domain.  Originating  
domains can "authorize" HELOs or even DKIM signatures.

There are no limits in the number of domains that can be authorized  
in this manner.  The "named reference" check involves a safe, single,  
small DNS transaction.

> reverse routes, but unfortunately that failed a giggle test.

You misunderstand the suggestion.  The scheme only requires a  
convention for where the "named reference" labels are placed within  
the originating domain.  This does not require anything as complex as  
reverse routes, etc.  The originating domain would directly list all  
authorized domains.

> As you wrote later "opt-out" doesn't work.

Agreed.  It is not safe to use Opt-Out links, and as structured in  
the CAN-SPAM law, it does not ensure this response does not cause  
even more spam.  Clicking on the Opt-Out link acknowledges a level of  
ignorance with respect to browser security.  Browser security remains  
a primary weak link, but spam remains a primary infection vector for  
these exploits.  Spam must be made illegal.

>> There should be an international agreement that bulk sending of  
>> unsolicited messages is illegal.
>
> sides of the spam problem.  Or of "misdirected bounces" wrt SPF and  
> 2821bis.  IANAL and all.

While I agree with your goals, SPF is simply not safe.

> From an IETF POV RFC 3865 offers anything that's needed for this  

You might be right, but I find this hard to believe.

> If it's an SPF FAIL it wasn't xyzzy.claranet.de, problem solved as  
> far as I'm concerned.  Similar GMane where I post this message.
>
> And if it's an SPF PASS it's either me, or a problem between me, my  
> ISP, and another user of this ISP (= none of your problems) - they  
> can add op=auth to their policy when they are ready for it.

In theory, you would be right, although this will likely cause some  
of your messages to not be delivered when forwarded.  In practice,  
this is an extremely dangerous mechanism for a DDoS standpoint that  
should not be employed.  This approach can be changed to utilize a  
single "named reference" instead.  When a "named reference" is used  
in conjunction with DKIM, even forwarded messages will not be lost,  
even those signed by your "authorized" provider.

-Doug