Subject: [Asrg] Proven solution for authenticating messages

From: [email-masked]
Date: Tue, 4 Mar 2003 09:58:40 +1300

Hi, I would like to offer a concept, as one of the tools 
necessary for a solution to this problem.

OBSERVATIONS: Firstly some observations about the other 
tools we have at our disposal:

1. Text filters (reject messages if "string" found): 
	- they may block/delete wanted messages (false negative)
	- they may allow unwanted messages (false positive)
	- spammers work actively to defeat such filters
	- they therefore create additional work to check for these
exceptions

2. Blacklists (reject messages from senders on the list):
	- they are reactive (applied after the unwanted message arrives)
	- they may exclude wanted senders if too broad
	- they are of limited use if email addresses can be spoofed

3. Whitelists (accept messages from senders on the list):
	- there must be some way of receiving from a new sender
	- they are of limited use if email addresses can be spoofed

Note that the tools are of limited use, because of email spoofing.  

In fact, I would assert that authentication is the heart of our
problem.  If a spammer can fake the FROM address of my best friend
(or your friendly tax dept), it will be very hard to automatically
delete that message - you're going to have to check it just in case.

CONCEPT: And now the concept...

The New Zealand government has developed a specification for 
securing Internet email (authentication/encryption/integrity), 
between agencies, using S/MIME gateways.
http://www.e-government.govt.nz/see/mail/index.asp

This system is in use by over 50% of government agencies in New Zealand
already.  It will be adopted by 98% of government agencies by December 
2003.  Agencies have chosen to implement it either with commercial off 
the shelf packages, or through the development of an open source version.

The specification is an interpretation of several RFCs:
http://www.e-government.govt.nz/docs/see-mail-bus-req-2-2/chapter1.html

If an ISP were to adopt the system, then a customer's FROM 
address, could match the email address(es) associated with the
username/password of the ISP account.  In this way, we could authenticate 
all messages between that ISP's customers and any other system user.

Because it happens at a server level, the customer never sees 
the complexity of PKI.  The servers automatically establish 
and maintain links with new servers they discover (so long as 
the server's CA is trusted).

Over time, whitelists and blacklists then become very useful.  Users
can choose not to receive any "anonymous" (non-authenticated) messages.
Senders who abuse their position can be put on a blacklist, and any
future authenticated messages from them are ignored.

More importantly, I can be sure that I will always receive messages
from people I trust without some filter getting in the way.

Obviously there will be issues to resolve.  For instance, free mail
companies such as Hotmail will probably be ignored by most people.

Regards, 
Mike Pearson, S.E.E. Manager                      http://www.see.govt.nz

Phone : +64  (4) 495-6769
Fax   : +64  (4) 495-6669  
Mobile: +64 (21) 631-731 

mailto: [email-masked]

************************************************************************
E-government Unit,                       http://www.e-government.govt.nz
STATE SERVICES COMMISSION                         http://www.ssc.govt.nz
Te Komihana O Nga Tari Kawanatanga
Level 4, 100 Molesworth St
PO Box 329, Wellington 6015, 
NEW ZEALAND 
************************************************************************
This email and any replies are subject to the Official Information Act 
1982, and may be made available under that Act.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 22:33:50 +0100

> 3. Whitelists (accept messages from senders on the list):

I agree that these three methods don't work properly.

> http://www.e-government.govt.nz/see/mail/index.asp

Naw, I don't see that this could work in the internet for those
reasons:

- Almost the same could be achieved by simply using the
  STARTTLS command of ESMTP. Our rackland server is configured
  to use it, but a view on the log files shows that extremely
  few other servers support this.

  S/MIME - precisely: the PKI -  is simply too complicated for most
  mail admins. Otherwise most relays would already use it.

  Why not simply use TLS if it already exists and is implemented? 
  Because people refuse to use it.

- The cryptographic approach depends on a working PKI. It works in 
  NZ government, because this is a centralized organization with a 
  single authority. Setting up a PKI in such an environment is easy.

  But how do you want to setup a PKI in the whole internet? All
  efforts to do so failed so far. There are even countries where such
  a use of cryptography is illegal. 

- Cryptographic keys can be stolen or get lost. Do you really believe
  that these keys will stay safe and secret on all those Windows boxes
  in the world? 

How would you establish such a S/MIME infrastructure in, lets say,
Northkorea, Iraq, some of the states of Africa?

Hadmut

---

From: Prasenjeet Dutta <[email-masked]>
Date: Tue, 04 Mar 2003 12:50:25 +0530

>   Because people refuse to use it.

It could also be because most PKI infrastructure is based on the X.509 
model, which (though scalable) requires folk needing a certificate to 
cough up cash to CAs like Verisign. Also, for secure personal 
communication (as opposed to electronic commerce), PGP has been arguably 
far more popular than S/MIME. Especially given its free, bottom-up 'web 
of trust' model, PGP may well succeed where the top-down X.509 has not.

Again, what is the goal of using TLS for email? Securing the messages? 
That opens up a new battle with the monitoring agencies. Or is it (from 
the anti-spam point of view) to let SMTP servers non-repudiably identify 
themselves? If this is the goal, then it can be done with far less 
overhead than TLS.

Digital signatures inserted by the *server* (not by the user, who should 
not have to bother with the complexity of this) to identify *itself*, 
using an  RFC 2440 infrastructure, may be more successful in making 
individual SMTP servers identifiable and accountable for what they spew 
onto the Internet. Consider this fragment:

O:  Received: from localhost by europa
O:    (Exim version 3.12 #1); Wed, 22 Jan 2003 07:10:06
O:  Origin-Server-Identity: public-key;
O:	europa.uri.com (12.10.58.222)
O:  Origin-Server-Key: <mailto:[email-masked]>
O:  Origin-Server-Signature: rfc2440; encoding=base64
O:	iQA/AwUAPi2tY1VioDO/jwwhEQIyrACg6HYQDh+ynXbfqSp+4hF3kfb6zQIAnRYN
O:	Ca1gPsBiRizLdYbtci4yVJRziQA/AwUAPi2tY1VioDO/jwwhEQIyrACg6HYQDh+y
O:	nXbfqSp+4hF3kfb6zQIAnRYNCa1gPsBiRizLdYbtci4yVJRz
O:	=1cuV
O:  Message-ID: <002b01c2c1b7$30889ab0$1c01010a@europa>

Here, the Origin-Server-Identity and Origin-Server-Key is signed and the 
signature is placed inline in the Origin-Server-Signature header. This 
signature can even be created offline as a one-time affair. The 
recipient server (or a plug-in within it) would have to compare the 
stated origin server name/IP address with the actual server name/IP 
address, and check if the key is trusted, as well as for revocation.

The best part is, given modern mail servers and their ability to run 
plug-ins, all of this is doable without any change to existing MTAs. No 
change is required to MUAs or users' email habits as well.

-- 
Prasenjeet Dutta
http://www.chaoszone.org/

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 10:39:23 +0100

> of trust' model, PGP may well succeed where the top-down X.509 has

PGP (as we know it) will never do this job, since it lacks the
structure that X.509 has. PGP trust is based on a cloud of friends and
acquaintances, you will never get a working trust structure covering
the world wide email network.

> themselves? If this is the goal, then it can be done with far less 

You miss the point. I didn't discuss the goal of TLS. 

What I wanted to say: That is a mechanism that already is 
implemented and widely spread. No need to install new software. 
And even that one is rarely used, because cryptography is still
to complicated for most mail admins. The very same problem 
will apply to the S/MIME approach once it is used outside a 
centralized organisation like the NZ gov. 

Secondly, the NZ S/MIME doesn't provide end-to-end security, only
relay-to-relay. The same effect can be achieved with TLS. TLS is
already available, but people simply don't use it.

> onto the Internet. Consider this fragment:

Again, you will never get a working PGP infrastructure reliably 
covering the whole e-mail world.

Hadmut

---

From: Prasenjeet Dutta <[email-masked]>
Date: Tue, 04 Mar 2003 16:26:35 +0530

Hadmut Danisch wrote:
>>cough up cash to CAs like Verisign.
> 
> 

I agree PGP's trust model does not scale well (however, it has lower 
overhead to set up). However, the idea of letting relays non-repudiably 
identify themselves to other relays is a sound one, I believe.

The only hitch is an infrastructural problem of getting a 
"relay-identity-only" CA up and running who'd handle the X.509 
infrastructure for handle certificate signing and revocation list 
management -- for little or no cost (cost obviously detering non-profits 
from using this).

Any entity registered with such a CA would satisfy Step #1 of Brad 
Templeton's plan for spam -- "Whitelist those who will be accountable 
for abuse", and we could reduce the problem set to dealing with rogue 
SMTP servers.

Is such a 'free' "relay-identity-only" CA feasible? (Perhaps running on 
donations from the community? Businesses spend enough on anti-spam 
software and bandwidth that they shouldn't mind paying to reduce the 
amount of spam they get.)

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 12:09:21 +0100

> management -- for little or no cost (cost obviously detering non-profits 
...
> amount of spam they get.)

Keep the road warriors in mind. People keep critizing my RMX proposal
because they want to be able to send e-mail from virtually anywhere
with their mobile computers. You can't address this problem with a 
relay-identity-only CA. It's actually just a different implementation
of the RMX approach to reduce the mail origins to a limited number
of authorized relays. It's just a different
authentication/authorization mechanism.

The second problem is that you will never get such a CA approach
sufficiently widely spread. What to do with countries which don't
allow cryptography? What to do with admins who don't understand
cryptography? What to do with stolen or lost key? You'll need a 
revocation infrastructure, usually based on web or ldap servers. 

regards
Hadmut

---

From: Roland <[email-masked]>
Date: Tue, 04 Mar 2003 12:38:48 +0000

--Prasenjeet Dutta wrote on 04.03.03 16:26 +0530:

> The only hitch is an infrastructural problem of getting a "relay-identity-only" CA up and running who'd handle the X.509 infrastructure for handle certificate signing and revocation list management -- for little or no cost (cost obviously detering
> non-profits from using this).
> 
> Any entity registered with such a CA would satisfy Step #1 of Brad Templeton's plan for spam -- "Whitelist those who will be accountable for abuse", and we could reduce the problem set to dealing with rogue SMTP servers.

Such a 'whitelist of accountable servers' would need no cryptography
at all and could also be distributed via dnswl (note the 'W').

Problem here: what constitutes 'accountable', how many unresolved or
ignored complaints will be needed to revoke the privilegies, how could
they proof an address indeed has passed the verified opt-in with the
exact same entity which sent the mail (which also requires to compare
both signup-page, the confirmation-request and the content of the mail
manually) without allowing the mainsleaze for listwashing.

This would require a trusted entity which does the whole confirmation
and managment, some kind of 'consent clearinghouse'.

Roland

---

From: Prasenjeet Dutta <[email-masked]>
Date: Tue, 04 Mar 2003 20:52:22 +0530

Hadmut Danisch wrote:
> relay-identity-only CA.

Actually, we can -- my original proposal at 
<http://www.chaoszone.org/misc/spam.html> proposed using 
digital-signature based non-repudiable relays *in addition to* what I 
called DNSMX (==RMX) lookups: the RMX technique solves the problem for 
the vast majority of considerate SMTP servers, while road warriors (of 
whom I have to count myself as one -- this mail is reaching you via a 
SMTP server on my laptop) could use the digital signature based 
approach. Either way, relays are unambiguously identified.

> It's actually just a different implementation

Indeed. The two complement each other quite well, I feel.

> cryptography?

In my original proposal, to *send* email, there is *no cryptography* 
involved -- you only need a static string that can be generated by a CA 
for you (or you can generate it yourself).

To receive mail, no cryptography is required either. To verify a relay's 
identity, a plug-in inside your MTA needs to verify a digital signature. 
(Most countries allow digital signatures because law-enforcement is 
typically very interested in non-repudiable messages.) However, if you 
live in a country where verifying digital signatures is not permitted, 
you can choose to not do this (and use RMX verification solely) or use a 
web-service approach to get the signature verified in a country that 
does allow signature-verification.

What about administrators who don't understand crypto? Because the work 
of signature verification (or RMX verification) is likely to be done by 
a plugin in an MTA (Spam-Assassin style), they usually would not have to 
know the gory details.

> What to do with stolen or lost key? You'll need a 

Stolen/Lost/Compromised Keys can be revoked. Revocation checking can be 
done as part of the standard key verification process. Key revocation is 
possible in both RFC 2440 as well as X.509, so it is more of an 
infrastructure issue. The revocation infrastructure could possibly be 
managed by an entity like spamhaus or any responsible entity, perhaps 
with an IETF charter and mandate.

---

From: Prasenjeet Dutta <[email-masked]>
Date: Tue, 04 Mar 2003 21:01:00 +0530

> Problem here: what constitutes 'accountable' [...]

I agree, and this is the biggest challenge in this proposal. We already 
have a clutch of CAs in place, but I think the for-profit approach for 
e-mail CAs/Consent 'clearinghouses' will not work very well. In my mind, 
I'd imagine a not-for-profit, international entity with a clear charter 
and mandate. They could be the successors of today's spamhaus et al.

Of course, there's no reason why there should be only one trusted 
entity: there could be several.

---

From: Adam Back <[email-masked]>
Date: Tue, 4 Mar 2003 20:07:24 +0000

I don't believe there are any countries where verifying digital
signatures is not permitted.  You're probably thinking of the largely
historic encryption regulations.  (There still remain some countries
which restrict encryption, but none that I know of that restrict
signatures.)

For example take a look at Bert-Jaap Koops "Crypto Law Survey":

	http://rechten.kub.nl/koops/cryptolaw/

Adam

On Tue, Mar 04, 2003 at 08:52:22PM +0530, Prasenjeet Dutta wrote:
> [...] However, if you live in a country where verifying digital
> signatures is not permitted,

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 21:26:35 +0100

> which restrict encryption, but none that I know of that restrict

Maybe it is prohibited to have a secret key at all...

A PKI for signatures can always be abused as a PKI for encryption.
There are countries and governments who don't permit this.

Hadmut

---

From: Matthias Leisi <[email-masked]>
Date: Tue, 4 Mar 2003 21:33:27 +0100

> If mail is signed with a certificate from a trusted CA that has met
> this test, it inherits the trust of that CA.  If mail comes from
> a country that gives the death penalty to spammers and enforces it,
> that's fine too.   However, the goal is to have as many was as
> people can think up to be accountable.

Most large-scale attempts with certification systems have
failed, especially if they require individual users to take
action - think PGP, which is fine as a technology, but does your
father use it?

But the concept of "inherited trust" is one that I keep thinking
of. Blacklists work quite well, and trustworthy blacklists work
even better; some have earned a good reputation due to their
consistent policy, while others have failed due to irrational
behaviour. 

So, the idea must have already been realized somewhere: why not
build trustworthy Whitelists of accountable, responsible mail
hosts? 

Of course, as with blacklists, there are policy issues with such
lists, as the maintainer might face incentives adverese to
general interest, which would have to be sorted out in one way
or the other. But once a series of whitelists is established, an
important issue raised by Brad should be solved:

> The one natural monopoly here is in aggregating traffic volume.  The
> throttles counting volume of mail coming from networks do need to
> join in a collective to share the volume data, otherwise you can't
> detect bulk mail. 

Lists are aggregates by definition ;)

Technically, whitelists are as trivial as blacklists: use some
agreed-upon IP range for DNS queries (e.g. 127.1.0.x). 

With both black- and whitelists being available, we could also
overcome the unsatisfying 1-0-view of blocking/allowing mail. An
average of the rating by different lists (weighted by
trustworthiness of the lists maintainer) should provide
sufficient accuracy in deciding what to do with a mail already
at the envelope stage of mail processing.

Matthias

-- 
Swiss Internet User Group                         http://www.siug.ch/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Templeton <[email-masked]>
Date: Tue, 4 Mar 2003 11:52:56 -0800

On Tue, Mar 04, 2003 at 09:01:00PM +0530, Prasenjeet Dutta wrote:
> I agree, and this is the biggest challenge in this proposal. We 
> already have a clutch of CAs in place, but I think the for-profit 
> approach for e-mail CAs/Consent 'clearinghouses' will not work very 

There are many different ways to be accountable, and only one global
test -- does the system of accountability work well enough to keep the
spam volume below an acceptable level.

The flaw as you present it, is that there is a natural economy of
scale, perhaps almost a natural monopoly, in having one list of
the addresses which can be held accountable for abuse.   That isn't
a hard and fast requirement -- each target using such a throttling
gateway could use a different list, or draw from a different set
of criteria.

That's even easy to implement.  The site gets to control their
MX to a server that follows the rules they like.  If a trusted site
connects there by accident, worst case is they are refused and thus
connect to the real server, which is next in the MX line.

The one natural monopoly here is in aggregating traffic volume.  The
throttles counting volume of mail coming from networks do need to
join in a collective to share the volume data, otherwise you can't
detect bulk mail.   You could have a small number of these aggregations
of volume data, but not too many.   However, nobody has to "own" this
aggregation, that just needs a protocol by which the data are shared,
and some trust system to only allow trusted people to contribute
data.

However, the main point of this philosophy is that this is the way
almost all rules in society are actually enforced.  We don't put
up battlements around our houses to protect them any more.  We
don't put police on every corner.  All we care about is that if
somebody does break the rules, they can be held accountable.  That is
a deterrent to those who would break the rules.

It's only in the most extreme cases that society works any other way,
and society is usually poorer when it does.   Airports are a modern
example.  In order to stop, rather than deter hijacking, we now
put up with flying becoming a horrendus and privacy-stripping
experience.

Spam, fortunately, isn't that bad.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Adam Back <[email-masked]>
Date: Tue, 4 Mar 2003 20:40:42 +0000

Which countries?

I really recommend that any anti-spam tech doesn't start out presuming
they can't use digital signatures for legal reasons!!

That position has never been taken in any internet security protocol
that I have heard.

Adam

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 22:19:02 +0100

> Which countries?

Oh, I bet you won't have much of a nice future in 
North Korea, Iraq, maybe China, and some other countries
in Africa, in far east, of the arabian countries ... 
if you insist on possessing a secret key. 

> That position has never been taken in any internet security protocol

Because most security protocols are to be used voluntarily and not
with strangers. They are "can use if you want" but not "must use"
protocols.

But here we are talking about protocols that virtually
_everybody_ on the world using the internet (and e-mail is a essential
part of internet use, isn't it?) will have to adopt. 

Is there any other internet security protocol that has gone so 
far?

Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 4 Mar 2003 14:49:46 -0700 (MST)

> From: Matthias Leisi <[email-masked]>

> build trustworthy Whitelists of accountable, responsible mail

That has often been proposed, but I think it is impractical for
several reasons.  One is that your whitelist is doubtless very
different from mine and every other whitelist.

Another fatal problem is that mobs are stupid and malicious, and moreso
the larger they are.  Up to a perhaps a few dozen people, you can
trust everyone to be careful, sane, and have good intentions.  With
a gross or more participants, you can be sure some are stupid and
incompetent and probably a few are malicious.  With a few dozen or
fewer, you don't need fancy formal mechanisms.  With a large group,
formal mechanisms cannot exclude the sloppy, lazy, or malicious.

> or the other. ...

I believe there are no blacklists that involve a lot of people and
that do not have major false positive problems.  The SBL comes closest,
but membership in its inner circle seems tight and carefully monitored.

] From: Clifton Royston <[email-masked]>

] ...
]   Would anyone consider it worthwhile for this group to put some focus
] on making existing email content analysis/filter tools (in particular
] anti-spam software) more interoperable?
]
]   I suggest a useful step in that direction to be defining a standard
] for how they should utilize mail headers to announce the results of
] their analysis.  Right now it seems that every program uses a different
] set of made up X-Headers in a different and incompatible way.  (Well,
] except for ours, which uses "Comments:" headers in a different and
] incompatible way.)
] ...

That's another often proposed idea that I think makes no sense in
practice.  A minor issue is the fact that differences among the X-
headers used by the many filters from SpamAsassin to blacklist taggers
are desirable.  You want to be able to apply different criteria to
the answers produced by different filters.  A DCC result is not
directly comparable to a SpamAssassin result.   

It wouldn't hurt to have a little more consistency among the tags,
but it would be a bad thing to try to make them sufficently consistent
that they could be machine-parsed by something like a single regular
expression.

The major problem is that "spam" is a local issue.  Even when
checked at the originating SMTP client (some ISPs use the DCC to
detect outgoing bulk mail), objectionable spam is determined locally.
There's no good reason for Microsoft to tell AOL what mail Hotmail
finds objectionable.  A humorous proof of that was the recent hoohaw
over the Microsoft blocking.

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

---

From: Adam Back <[email-masked]>
Date: Tue, 4 Mar 2003 22:00:17 +0000

There are a number of examples where signatures have been globally
deployed apparently without any issues with crypto laws.

For example S/MIME (outlook, netscape mail etc).

Adam

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 4 Mar 2003 17:19:08 -0500

Hadmut Danisch wrote concerning secrets:
> here we are talking about protocols that virtually 
> _everybody_ on the world using the internet (and e-mail 
> is a essential part of internet use, isn't it?) will 
> have to adopt. 

	I believe the discussion here is focused on authentication, not
encryption. Thus, the focus is primarily on signatures. As such, the
discussion does not include mechanisms for "hiding" information or even
implementations that would allow passing secrets between people.
	As I understand it, the problem of "private" or "encrypted"
communications is not within the scope of the ASRG charter.
	Even if there were countries that prohibit the use of signature
technologies, there is still a range of methods that could be used, in
part, by residents of those countries. These include, for instance, the
approaches that involve "token-passing". For instance, the "single-user"
email addresses that I've discussed in other mail messages or the
"email-cookie" ideas that have been proposed. Use of these methods would
allow one in a restrictive jurisdiction, or anyone who did not have a
signing ability for some other reason, to send mail to someone who was
free to use the technology and generate the appropriate tokens. (Note: I
am well aware of the fact that these "single-sided" approaches have a
number of weaknesses. However, something may be considered to be better
than nothing.)

		bob wyman

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 4 Mar 2003 23:46:12 +0100

> implementations that would allow passing secrets between people.

I fully agree with that. However, a PKI built for signing can
easily be turned into a PKI for encryption by the end users by
using publicly known cryptographical methods.

Thus, a government interested in prohibiting encryption/privacy
has to prohibit digital signatures as well. That's the problem.

This means: You cannot presume that use of signatures is 
unrestricted everywhere. 

Hadmut

---

From: Ben Laurie <[email-masked]>
Date: Tue, 04 Mar 2003 22:48:50 +0000

> part of internet use, isn't it?) will have to adopt. 

Sounds to me like an excellent reason to insist that crypto is used.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Brad Templeton <[email-masked]>
Date: Tue, 4 Mar 2003 18:13:40 -0800

I apologize if these issues came up before I joined the list but...

a) All existing e-mail signature tools sign the bodies of messages,
not the headers.  They have no way to authenticate the headers unless
they duplicate them in the body and your tool compares them.  So
they don't do a lot to prevent forgeries of headers, subject lines
etc. which are pretty important in this case.

b) X.509 uses identity certificates rather than attribute certs, and
the certs are HUGE and people would get quite annoyed attaching 5K
to each e-mail.

c) Identity certs are evil, did I mention that? :-)

d) Microsoft outlook supports S/MIME and x.509 but in a terrible way.
If you turn it on, you get queried with dialog boxes about access
to your private key with every email you send. (plus every email
you receive encrypted.)

e) You can declare you demand signed mail, but what good will that
do you during the early period when nobody is signing?  You have
to have some other avenue for them.   And why should people sign if
the other avenue exists?  It's a tradeoff on how hard you make the
avenue.  Make it too hard and lose mail.  Make it too easy and
nobody feels the need to get all new email software and a cert.

Frankly, ask me to do anything particuarly hard just to send you
a mail, and I'm going to say "fuck you" unless I really had a
strong interest in sending that mail.  If I was sending it to help
you, because of request on your web page or in a posting, and I get
more than the simplest of challenges, I will just discard the mail.

f) You still need systems to allow anonymous mail (just not in bulk)
and not have everybody by default refusing it because it might be
spam.