New UUCP mapping project?

[van...@vsta.org]

So, given that UUCP as a "real" network is no longer an issue, wouldn't it be
cool to reconstitute a UUCP network (over TCP/IP, no interest in modems here)
including a map of the participants? My old nodename, "baltor" (included in
the last UUCP maps ever published), has started talking UUCP again, and
connects to SDF. Anybody else out there? Is this thing on?

--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[Bill Gunshannon]

In article <a4uvtq...@mid.individual.net>,

van...@vsta.org writes:
> So, given that UUCP as a "real" network is no longer an issue, wouldn't it be
> cool to reconstitute a UUCP network (over TCP/IP, no interest in modems here)
> including a map of the participants? My old nodename, "baltor" (included in
> the last UUCP maps ever published), has started talking UUCP again, and
> connects to SDF. Anybody else out there? Is this thing on?
>

I have suggested this numerous times. It is actually a very good way to
cut down on the SPAM problem.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Moritz Wilhelmy]

Hello,

Count me in!

We're setting up a some kind of retro BBS (with email support), and to
make it authentic, we're going to use software made in 1994.

We already got Slackware 2.0 running on a (not yet old enough, looking
for downgrades) K6-2 machine, which is running Smail. Local email works,
haven't tried sending mail or anything else for that matter via UUCP.

Having never dealt with UUCP before, I always wanted to look into it.

It's currently planned that we're going to support modems as well as
TCP/IP. I'd also be interested in usenet access via UUCP, but that's a
different story.


Best,

Moritz

--
When mailing, please swap local part and domain, and drop the .invalid

[sam...@gmail.com]

We have a whole bunch of hosts connected to UUHEC.NET, check it out at http://www.uuhec.net/

We'd be happy to participate in any mapping project you're running...

[Bill Gunshannon]

In article <9873d383-7428-4b9e...@googlegroups.com>,

I have been suggesting for years that UUCPNET should be revived. And as
much more than a fun, nostalgia project. It has a feature that could go
a long ways towards solving the SPAM and Email Virus epidemic. But I
have never been able to get people to even consider it.

[Ivan Shmakov]

>>>>> Bill Gunshannon <bi...@server2.cs.scranton.edu> writes:

[Cross-posting to news:news.misc, just in case, yet /leaving/
Followup-To: comp.mail.uucp.]

[...]

> I have been suggesting for years that UUCPNET should be revived. And
> as much more than a fun, nostalgia project. It has a feature that
> could go a long ways towards solving the SPAM and Email Virus
> epidemic.

Could you please provide more details on this? I know of no
particular UUCP feature which can make spam any less likely
there than in the ESMTP-based email.

... Except for, perhaps, that UUCP can be configured to only
allow mail from whitelisted hosts (but so can be the modern
MTAs), and that an UUCP network is much more likely to be just a
"handful" of nodes, so reaching the other nodes' postmasters
would be much less of a lost cause it is in the ESMTP world.

> But I have never been able to get people to even consider it.

FWIW, as per Wagner's Children of Space [1], in the year of
2525^W 2227, Usenet is still alive. And so is UUCP, for neither
ESMTP and NNTP prove themselves adequate for interstellar data
transfer.

[1] http://www.wagner.pp.ru/~vitus/fiction/spacians.html

--
FSF associate member #7257

[Bill Gunshannon]

In article <87vbzln...@violet.siamics.net>,

Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server2.cs.scranton.edu> writes:
>
> [Cross-posting to news:news.misc, just in case, yet /leaving/
> Followup-To: comp.mail.uucp.]
>
> [...]
>
> > I have been suggesting for years that UUCPNET should be revived. And
> > as much more than a fun, nostalgia project. It has a feature that
> > could go a long ways towards solving the SPAM and Email Virus
> > epidemic.
>
> Could you please provide more details on this? I know of no
> particular UUCP feature which can make spam any less likely
> there than in the ESMTP-based email.

SPAM is not a technical problem, it is a social problem. It is a well
documented fact that the largest percentage of SPAM comes from machines
that should not be sending email at all (ie. zombied PCs). The biggest
advantage of UUCP is email is only exchanged between people who agree
to do it. This agreement can be based on a written agreement with legally
enforcable penalties for violation. But even without that there is always
the threat of ostracization. Violate the rules, get thrown out of the
network. Shunning has long worked for the Amish. :-)

Now, before you say that it would greatly limit who you could send email
to or receive it from, yes, you are right. At least at first. But even
then it would have the immediate effect of making filtering easier. You
would now have a netork (hopefully growing every day) of systems who could
be trusted and thus could be "white-listed". Networks of users with
shared interests and therefore larger groups of users likely to need to
interchange with each other could be formed (like schools or software
developers) and interconnected to extend the range of the new UUCP network.

The biggest disadvantage to UUCP from the old days was the cost of the
telephone calls. This disadvantage is completely gone today as UUCP can
be run across the smae medium as SMTP.

>
> ... Except for, perhaps, that UUCP can be configured to only
> allow mail from whitelisted hosts (but so can be the modern
> MTAs), and that an UUCP network is much more likely to be just a
> "handful" of nodes, so reaching the other nodes' postmasters
> would be much less of a lost cause it is in the ESMTP world.

See above. It is not som much "white-listed" as UUCP hosts have to
establish a prior arrangement with each other in order to exchange
email. This means there will be an agreement on what is and is not
allowable traffic. Violation of a re-arranged agreement woudl likely
mean being cut off from the network. Having done this for as long as
I have I expect that the people who would be doing this are very unlikely
to allow such anti-social behavior.

>
> > But I have never been able to get people to even consider it.
>
> FWIW, as per Wagner's Children of Space [1], in the year of
> 2525^W 2227, Usenet is still alive. And so is UUCP, for neither
> ESMTP and NNTP prove themselves adequate for interstellar data
> transfer.
>
> [1] http://www.wagner.pp.ru/~vitus/fiction/spacians.html

Not surprising. I am an Amateur Radio Operator. Back in the early days of
Packet Radio I ran some digipeaters that saw lots of traffic thru them. I
also did a lot of experimenting with running UUCP over AX.25. I never really
understood why hams went to the trouble of reinventing the wheel with the
inefficient and cludgy BBS system when there was already a system for
distributing email and discussions that worked really well on Packet Radio.
NIH Syndrome, I imagine.

[Ivan Shmakov]

>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>> Bill Gunshannon <bi...@server2.cs.scranton.edu> writes:

[...]

>>> I have been suggesting for years that UUCPNET should be revived.
>>> And as much more than a fun, nostalgia project. It has a feature
>>> that could go a long ways towards solving the SPAM and Email Virus
>>> epidemic.

>> Could you please provide more details on this? I know of no
>> particular UUCP feature which can make spam any less likely there
>> than in the ESMTP-based email.

> SPAM is not a technical problem, it is a social problem.

By the very same argument, UUCP isn't a proper solution, either.

> It is a well documented fact that the largest percentage of SPAM
> comes from machines that should not be sending email at all
> (ie. zombied PCs).

... The issue which can more or less be cured by using certain
DNSBLs, together with checking the validity of MAIL FROM:
domain, etc. Unfortunately, there appears to be a fair share of
free-of-charge Email providers which, while valid transfer nodes
per se, let some occasional spam pass through.

> The biggest advantage of UUCP is email is only exchanged between
> people who agree to do it. This agreement can be based on a written

> agreement with legally enforceable penalties for violation. But even

> without that there is always the threat of ostracization. Violate
> the rules, get thrown out of the network. Shunning has long worked
> for the Amish. :-)

Well, that's the point: one runs a node, and it accepts mail
only from the nodes "trusted" by the operator. In essence, it's
a good old explicit whitelist, which could be implemented on a
network of ESMTP MTAs just as well.

(Which I'd even thought of doing, though later realizing that it
doesn't solve the whole problem, as per below.)

> Now, before you say that it would greatly limit who you could send
> email to or receive it from, yes, you are right. At least at first.
> But even then it would have the immediate effect of making filtering

> easier. You would now have a network (hopefully growing every day) of

> systems who could be trusted and thus could be "white-listed".

My guess would be as soon as this system gets its 1e6th user, --
"shunning" would no longer be all that effective an approach.

[...]

> See above. It is not so much "white-listed" as UUCP hosts have to

> establish a prior arrangement with each other in order to exchange
> email.

Yet again, -- this is also possible with ESMTP-based email.

> This means there will be an agreement on what is and is not allowable

> traffic. Violation of a re-arranged agreement would likely mean

> being cut off from the network.

Not quite. Consider, for instance, two mail hubs, A and B,
serving some 128 users each. Now, a user of a mail node C,
which is indirectly connected to A, sends a inappropriate
message to user D, which is indirectly connected to B. Around
that same time, a user E, indirectly connected to B, sends a
similarly inappropriate mail to user F (A.) Or,
pseudographically speaking:

C -> .. -> A -> B -> .. -> D

E <- .. <- A <- B <- .. <- F

With the first message being reported, the postmaster @ A
accuses the postmaster @ B of breaching the agreement. But at
the same time, with the second message being reported, the
postmaster @ B accuses the postmaster @ A of the same.

The question is: do A and B sever their link (thus breaking
connectivity for a number of users), or do they tolerate the
issue (thus effectively accepting occasional spam traffic)?

[...]

... And as for the solution, the essence of email, whether based
on ESMTP, UUCP, FTN, or something else, -- is routing. Now that
we've got some sort of Internet connectivity (even if NATed) for
every Nth person on the planet, we can pretty much rely on
Internet routing itself for routing any traffic, including what
could be very much like email of today. Pseudographically
speaking (and omitting the details) instead of doing it like:

Alice -> MTA -> .. -> MTA -> Bob

We do it either:

Alice -> Bob

Or, should there be no Internet connectivity at any given time
(including the case of NAT):

Alice -> Blobhost -> Bob

Then, the messages are encrypted and signed, and every Alice,
Bob and Charlie are free to establish their own whitelist, as
well as rely on some sort of a Web of Trust to be done on top.

[Bill Gunshannon]

In article <87r4a9n...@violet.siamics.net>,

Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server2.cs.scranton.edu> writes:
>
> [...]
>
> >>> I have been suggesting for years that UUCPNET should be revived.
> >>> And as much more than a fun, nostalgia project. It has a feature
> >>> that could go a long ways towards solving the SPAM and Email Virus
> >>> epidemic.
>
> >> Could you please provide more details on this? I know of no
> >> particular UUCP feature which can make spam any less likely there
> >> than in the ESMTP-based email.
>
> > SPAM is not a technical problem, it is a social problem.
>
> By the very same argument, UUCP isn't a proper solution, either.

UUCP is a protocol that requires a social connection between the people
who are going to exchange email. Outsiders can not inject garbage in.
Granted the current SMTP system could be fixed, but there is a group
woh have a vested interest in keeping it the way they do for personal
profit and that is more than enough to keep it from being fixed. The
fix requies taking it out of their hands to control. Establishing a
new email network can do that and UUCP is an already existing and tested
tool to perform the task.

>
> > It is a well documented fact that the largest percentage of SPAM
> > comes from machines that should not be sending email at all
> > (ie. zombied PCs).
>
> ... The issue which can more or less be cured by using certain
> DNSBLs, together with checking the validity of MAIL FROM:
> domain, etc. Unfortunately, there appears to be a fair share of
> free-of-charge Email providers which, while valid transfer nodes
> per se, let some occasional spam pass through.

"Some occaisional"? Try the majority of current emails. Black lists
have their problems, too. False positives. Not every bad sysytem shows
up in a DNSBL. etc...

Actualy, if everyone who controls a network would block outgoing port 25
traffic from everyone but legitimate MTA hosts most of the problem would
go away. But after all these years we know that is not going to happen.

What does "indirectly connected" mean? In UUCP every node is durectly
connected to someone. Whoever "C" is connected to cuts them off if
they violate the agreement. Period. "C" is now out of the picture.
If "C" cares they would have taken the steps necessary to prevent it.
If they don't care, then Good Bye.

> sends a inappropriate
> message to user D, which is indirectly connected to B. Around
> that same time, a user E, indirectly connected to B, sends a
> similarly inappropriate mail to user F (A.) Or,
> pseudographically speaking:
>
> C -> .. -> A -> B -> .. -> D
>
> E <- .. <- A <- B <- .. <- F
>
> With the first message being reported, the postmaster @ A
> accuses the postmaster @ B of breaching the agreement. But at
> the same time, with the second message being reported, the
> postmaster @ B accuses the postmaster @ A of the same.

Do you know how UUCP works? The postmasters at "A" and "B" know
exactly where the offending email originated. I think your got your
"E" and "F" confused but the same thing happens on that link that
happened to "C".

>
> The question is: do A and B sever their link (thus breaking
> connectivity for a number of users), or do they tolerate the
> issue (thus effectively accepting occasional spam traffic)?

No, they terminate the node that originated the offending email.
UUCP is no different than any other INTERNET connected service.
There does not need to be only one possible path and single point
of failure. As people join the network they can agree to accept
from any other node in the network. Thus creating a large mesh
where, unlike the old days of UUCP, a message does not have to
travel thru a dozen other nodes to get somewhere. It can, it just
isn't necessary. Of course, there is nothing to stop someone from
setting up a machine as a "hub" for the sole purpose of having a single
central point to make routing easier. Or maybe a half dozen or so
people doing it to once again address the single point of failure
issue. Which is exactly how UUNET got started.

>
> [...]
>
> ... And as for the solution, the essence of email, whether based
> on ESMTP, UUCP, FTN, or something else, -- is routing. Now that
> we've got some sort of Internet connectivity (even if NATed) for
> every Nth person on the planet, we can pretty much rely on
> Internet routing itself for routing any traffic, including what
> could be very much like email of today. Pseudographically
> speaking (and omitting the details) instead of doing it like:
>
> Alice -> MTA -> .. -> MTA -> Bob
>
> We do it either:
>
> Alice -> Bob
>
> Or, should there be no Internet connectivity at any given time
> (including the case of NAT):
>
> Alice -> Blobhost -> Bob
>
> Then, the messages are encrypted and signed, and every Alice,
> Bob and Charlie are free to establish their own whitelist, as
> well as rely on some sort of a Web of Trust to be done on top.

All of this is in use today. And yet, SPAM persists. Whitelists only
work if you already know everyone you will want to receive email from
and can trust. With a system in place that makes spoofing addresses
trivial filtering at the user level is all but useless. And filtering
at the MTA level runs the risk of extremely high false positives resulting
in large numbers of missed emails and very little likely reduction in
SPAM.


The other nice thing about my suggestion is that I am not suggesting
replacement of SMTP. Let the world go on as it has. Join a UUCP network
if you want. In my case, my MTA would decide, based on the address,
which way to send the email. But I would have this list of known trusted
email hosts that I could use to re-write headers adding something that
makes user level filtering of "known safe" vs. "unknown" emails arriving
at the users mailbox. No one has to use it. But I suspect that it would
not take long before peopel who prefer to keep their email limited to
real communications would start to join in. Other advantages. There are
people who would like to run their own email servers even though they are
coming from residential connections. Many of these people knwo what they
are doing (like me!!). Blocking port 25 (if it ever happened) would
permanently stop them under the current system. DNSBL's stop many of them
now. And DYNDNS doesn't always work for email servers either because of
reverse lookups going back to the original ISP's DNS resulting in a
mis-match of names. Something my email server rejects immediately. The
proposed system creates a way for an individual who is willing to play
by the rules to run an email server of their own legitimately. Especially
useful if one only wishes to communicate with a small group of people,
perhaps researchers with common interests.

I am not suggesting forcing anyone to do this. But I would really like
to find a bunch of people interested enough to give it a try. Personally,
I really don't see any down side to it at all. At worst, it accomplishes
nothing. At best it might help clean up the morass that we live in today.

[Ivan Shmakov]

>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:

>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:

[...]

>>> SPAM is not a technical problem, it is a social problem.

>> By the very same argument, UUCP isn't a proper solution, either.

> UUCP is a protocol that requires a social connection between the
> people who are going to exchange email.

Not at all: it's the matter of policy, not protocol. What on
Earth could prevent me from starting a UUCP network with an
free-of-charge instant registration form open to the whole Web?

Conversely, what could prevent me from starting an ESMTP network
with explicit trust between the nodes, requiring a photo ID
verification to join it?

> Outsiders can not inject garbage in. Granted the current SMTP system

> could be fixed, but there is a group who have a vested interest in

> keeping it the way they do for personal profit and that is more than

> enough to keep it from being fixed. The fix requires taking it out

> of their hands to control. Establishing a new email network can do
> that

Yes.

> and UUCP is an already existing and tested tool to perform the task.

And so is ESMTP.

[...]

>> ... The issue which can more or less be cured by using certain
>> DNSBLs, together with checking the validity of MAIL FROM: domain,
>> etc. Unfortunately, there appears to be a fair share of
>> free-of-charge Email providers which, while valid transfer nodes per
>> se, let some occasional spam pass through.

> "Some occasional"? Try the majority of current emails.

I'm yet to analyze my recent logs. Hopefully I'll post
(probably to news:comp.mail.misc) the results within the next
few days.

> Black lists have their problems, too. False positives.

Are there many? (But then, my systems currently do graylisting
for DNSBLed peers.)

> Not every bad system shows up in a DNSBL. etc...

Alas.

> Actually, if everyone who controls a network would block outgoing

> port 25 traffic from everyone but legitimate MTA hosts most of the
> problem would go away. But after all these years we know that is not
> going to happen.

... Unless a "new network" is started, which is the crux of the
suggestion above. (With my point being that the protocol is
secondary to the policy.)

[...]

>>> This means there will be an agreement on what is and is not
>>> allowable traffic. Violation of a re-arranged agreement would
>>> likely mean being cut off from the network.

>> Not quite. Consider, for instance, two mail hubs, A and B, serving
>> some 128 users each. Now, a user of a mail node C, which is
>> indirectly connected to A,

> What does "indirectly connected" mean? In UUCP every node is

> directly connected to someone.

And if B is connected to A and C, then A and C themselves are
indirectly connected through B. (Unless they are directly
connected at the same time, that is.)

> Whoever "C" is connected to cuts them off if they violate the
> agreement. Period. "C" is now out of the picture. If "C" cares
> they would have taken the steps necessary to prevent it. If they
> don't care, then Good Bye.

The first issue is that while the message is out of the
agreement between A and B, it may very well be in agreement
between C and its uplink. (Think of nodes belonging to
different jurisdictions, for instance.)

[...]

>> Or, pseudographically speaking:

>> C -> .. -> A -> B -> .. -> D

>> E <- .. <- A <- B <- .. <- F

>> With the first message being reported, the postmaster @ A accuses
>> the postmaster @ B of breaching the agreement. But at the same
>> time, with the second message being reported, the postmaster @ B
>> accuses the postmaster @ A of the same.

> Do you know how UUCP works?

FWIW, I've ran a tiny UUCP network in my locality.

> The postmasters at "A" and "B" know exactly where the offending email
> originated.

Not at all: the data could be forged, unless somehow protected.
(And that's a technical issue, as of yet unresolved, to the best
of my knowledge, by UUCP.)

But here, I was referring more to the resolution mechanism,
which (unless I be mistaken) is mandated by the FidoNet policy:
if the C "uplink" fails to cut access to C, then the access is
cut for the "uplink" itself, possibly recursing all the way "up"
to the A <-> B link.

> I think your got your "E" and "F" confused

Indeed, I stand corrected.

> but the same thing happens on that link that happened to "C".

[...]

> No, they terminate the node that originated the offending email.

The point is that it'd be the responsibility of the direct link
of that node, which may end up being unreachable at any given
time.

> UUCP is no different than any other INTERNET connected service.

(And to the Internet itself, FTM.)

> There does not need to be only one possible path and single point of
> failure. As people join the network they can agree to accept from
> any other node in the network. Thus creating a large mesh where,
> unlike the old days of UUCP, a message does not have to travel thru a
> dozen other nodes to get somewhere.

Yet the problem with meshes like this is that every single link
is someone's potential headache. And even more so if the
misbehaving node cut from one side of the network could reappear
from the other, which is one more thing for the policy to cover.

[...]

>> Pseudographically speaking (and omitting the details) instead of
>> doing it like:

>> Alice -> MTA -> .. -> MTA -> Bob

>> We do it either:

>> Alice -> Bob

>> Or, should there be no Internet connectivity at any given time
>> (including the case of NAT):

>> Alice -> Blobhost -> Bob

>> Then, the messages are encrypted and signed, and every Alice, Bob
>> and Charlie are free to establish their own whitelist, as well as
>> rely on some sort of a Web of Trust to be done on top.

> All of this is in use today. And yet, SPAM persists. Whitelists
> only work if you already know everyone you will want to receive email
> from and can trust.

Which is no different to the proposed UUCP network.

> With a system in place that makes spoofing addresses trivial
> filtering at the user level is all but useless.

This is addressed by the "the messages are encrypted and signed"
requirement above.

> And filtering at the MTA level runs the risk of extremely high false
> positives resulting in large numbers of missed emails and very little
> likely reduction in SPAM.

Well, to stress it out: my scheme above has no MTAs whatsoever.

> The other nice thing about my suggestion is that I am not suggesting
> replacement of SMTP. Let the world go on as it has. Join a UUCP
> network if you want.

And the nice point about /my/ suggestion is that you can use the
better maintained ESMTP software instead -- the rest being
exactly the same.

(FTR, I've actually made two suggestions: one is to use ESMTP in
a "closed" network, and the other is to abandon the traditional
"routable" mail -- and thus MTAs, ESMTP, UUCP, etc. --
altogether.)

[...]

> The proposed system creates a way for an individual who is willing to
> play by the rules to run an email server of their own legitimately.

FWIW, I'm loosely working on a solution to this exact problem.
I'd welcome betatesters interested in configuring an ESMTPS
implementation (and maintaining IPv6 connectivity.)

> Especially useful if one only wishes to communicate with a small
> group of people, perhaps researchers with common interests.

... However, my solution is intended to be "open," allowing
routing to and from the Internet. (Should the addresses become
known to the abusers, that is.)

[...]

[Bill Gunshannon]

In article <87mwkxmz...@violet.siamics.net>,

Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>
> [...]
>
> >>> SPAM is not a technical problem, it is a social problem.
>
> >> By the very same argument, UUCP isn't a proper solution, either.
>
> > UUCP is a protocol that requires a social connection between the
> > people who are going to exchange email.
>
> Not at all: it's the matter of policy, not protocol.

Sorry, the confussion of the language. i didn't mean the UUCP protocol
at the protocol level requierd a social connection, but the servers
require it in order to exchange email. Joe random machine can not just
send email to a UUCP node like he can to an SMTP MTA. The node has to
be aware of his existence and have set up the necessary information for
him to connect before email will be accepted.

> What on
> Earth could prevent me from starting a UUCP network with an
> free-of-charge instant registration form open to the whole Web?

Nothing. But you won't talk to me. And none of your users will be able
to send email to me via UUCP. They can still send it via SMTP and you
are free to gatewaty it. But they will still show up at my site as
"un-trusted" and be marked accordingly so that my users can easily filter
it.

>
> Conversely, what could prevent me from starting an ESMTP network
> with explicit trust between the nodes, requiring a photo ID
> verification to join it?

Nothing. The one difference I see between using UUCP and ESMTP (at least
as I understand ESMTP) while individual agreements and information can be
required using UUCP it would also be possible to have a network agreement
by which you agree to accept other people's judgement of "trusted" and let
UUCP email hop between nodes rather than being a strict point-to-point
like SMTP/ESMTP is. Thus reducing the overhead and administration. But
then, this was kind of implied when I mentioned people setting up "hubs".
ESMTP, as I understand it, would require separate login information for
every single site you wanted to exchange email with. This could become
an administrative nightmare for anything but the smallest network.

>
> > Outsiders can not inject garbage in. Granted the current SMTP system
> > could be fixed, but there is a group who have a vested interest in
> > keeping it the way they do for personal profit and that is more than
> > enough to keep it from being fixed. The fix requires taking it out
> > of their hands to control. Establishing a new email network can do
> > that
>
> Yes.
>
> > and UUCP is an already existing and tested tool to perform the task.
>
> And so is ESMTP.

See comment above. If the cure involves more work than what it currently
takes to try to fight SPAM who would do it?

>
> [...]
>
> >> ... The issue which can more or less be cured by using certain
> >> DNSBLs, together with checking the validity of MAIL FROM: domain,
> >> etc. Unfortunately, there appears to be a fair share of
> >> free-of-charge Email providers which, while valid transfer nodes per
> >> se, let some occasional spam pass through.
>
> > "Some occasional"? Try the majority of current emails.
>
> I'm yet to analyze my recent logs. Hopefully I'll post
> (probably to news:comp.mail.misc) the results within the next
> few days.

I use DNSBL's with our MTA. I personally still get 20 times as much SPAM
as real email and that is with personal procmail filtering. I am getting
ready to try yet another anti-SPAM system but I have little hope of it
being able to defeat the SPAMMERS. And, all of this still leaves the fact
that even if you filter it from your mailbox, your network and MTA still
had to waste the resource moving it around the world. Much better to stop
it at the originating node by not accepting it in the first place.

>
> > Black lists have their problems, too. False positives.
>
> Are there many? (But then, my systems currently do graylisting
> for DNSBLed peers.)

Brings up the old question we have discussed here. "How many valid email
messages didn't you receive because of filtering?" How do you answer that
question? Any false positives are too many.

>
> > Not every bad system shows up in a DNSBL. etc...
>
> Alas.
>
> > Actually, if everyone who controls a network would block outgoing
> > port 25 traffic from everyone but legitimate MTA hosts most of the
> > problem would go away. But after all these years we know that is not
> > going to happen.
>
> ... Unless a "new network" is started,

A new network was started. INTERNET II. But a separate network will
never catch on because too much stuff is already over here. My proposal
runs on the existing infrastructure coexists with existing systems with
little if any affect on the user community. It can provide an improvement
in the way things work with a minimal requirement on the users. On the
other hand, it can provide a way for users to make use of things like
very functional white-listing and black-listing with a better chance
of reducing false positives.

> which is the crux of the
> suggestion above. (With my point being that the protocol is
> secondary to the policy.)

Quite true. And the average email sysadmin has no say whatsoever in the
policy in use on the current INTERNET. But, by overlaying this with a UUCP
email network these email admins can take control of at least a small part
of it. They would set the policy for their overlayed network.

>
> [...]
>
> >>> This means there will be an agreement on what is and is not
> >>> allowable traffic. Violation of a re-arranged agreement would
> >>> likely mean being cut off from the network.
>
> >> Not quite. Consider, for instance, two mail hubs, A and B, serving
> >> some 128 users each. Now, a user of a mail node C, which is
> >> indirectly connected to A,
>
> > What does "indirectly connected" mean? In UUCP every node is
> > directly connected to someone.
>
> And if B is connected to A and C, then A and C themselves are
> indirectly connected through B. (Unless they are directly
> connected at the same time, that is.)

OK. That was what I assumed for my explanation.

>
> > Whoever "C" is connected to cuts them off if they violate the
> > agreement. Period. "C" is now out of the picture. If "C" cares
> > they would have taken the steps necessary to prevent it. If they
> > don't care, then Good Bye.
>
> The first issue is that while the message is out of the
> agreement between A and B, it may very well be in agreement
> between C and its uplink. (Think of nodes belonging to
> different jurisdictions, for instance.)

You seem to have missed the point. There aren't different agreements.
If "B" does not impose the same limits on "C" that he agreed to with
"A", then "B" is in violation and gets cut off, which, in your example
also cuts off "C". But the point is that unlike the current situation
where everyone does as they please this network will have a set of rules.
Call it an "Acceptable Use Policy" as that is a well understood concept
by this point. It applies to anyone who wishes to connect to the network.
This is not to say that anyone can not impose stricter requirements but
these would be the minimum acceptable standards that everyone must abide
by or be disconnected.

>
> [...]
>
> >> Or, pseudographically speaking:
>
> >> C -> .. -> A -> B -> .. -> D
>
> >> E <- .. <- A <- B <- .. <- F
>
> >> With the first message being reported, the postmaster @ A accuses
> >> the postmaster @ B of breaching the agreement. But at the same
> >> time, with the second message being reported, the postmaster @ B
> >> accuses the postmaster @ A of the same.
>
> > Do you know how UUCP works?
>
> FWIW, I've ran a tiny UUCP network in my locality.
>
> > The postmasters at "A" and "B" know exactly where the offending email
> > originated.
>
> Not at all: the data could be forged, unless somehow protected.

Not likely.
Using your example:

"C" connects to "B" sends message. "B" creates the Path: header that says
joeuser!C!B
He knows where it came from. "C" had to login using credentials not known
by users, only the UUCP Admin. he can't connect as anyone else and he can't
control what "B" puts in the Path: header. He can try to make it look like
it came to him from somewhere else, but given that much of this is going to
be point-to-point or a very small number of hops it is unlikely to work.
And users don't get to fudge witht he Path: line. It is easily detectable
and pretty much guaranteed to be found out.

Even forged SMTP headers are easy to determine and they have no such
safeguards.

> (And that's a technical issue, as of yet unresolved, to the best
> of my knowledge, by UUCP.)

Was worked out decades ago, actually.

>
> But here, I was referring more to the resolution mechanism,
> which (unless I be mistaken) is mandated by the FidoNet policy:

Sorry, I used to use Fido but have no idea what their rules were.

> if the C "uplink" fails to cut access to C, then the access is
> cut for the "uplink" itself, possibly recursing all the way "up"
> to the A <-> B link.

Yes. What else would you expect? But remember, this is a proposal
for serious email admins who want to solve a serious problem. IF the
problem even occured, do you really think that "B" is somehow going to
risk his inclussion in the network to shield "C"? I certainly wouldn't.
He would be gone in a heartbeat.

>
> > I think your got your "E" and "F" confused
>
> Indeed, I stand corrected.
>
> > but the same thing happens on that link that happened to "C".
>
> [...]
>
> > No, they terminate the node that originated the offending email.
>
> The point is that it'd be the responsibility of the direct link
> of that node, which may end up being unreachable at any given
> time.

Don't understand this statement. Yes, it would be the responsibility of
the node the offender is directly connected to, which could be a number
of nodes. And, based on a legitimate complaint by any upstream nodes
all nodes providing a connection to "C" would sever them.

>
> > UUCP is no different than any other INTERNET connected service.
>
> (And to the Internet itself, FTM.)
>
> > There does not need to be only one possible path and single point of
> > failure. As people join the network they can agree to accept from
> > any other node in the network. Thus creating a large mesh where,
> > unlike the old days of UUCP, a message does not have to travel thru a
> > dozen other nodes to get somewhere.
>
> Yet the problem with meshes like this is that every single link
> is someone's potential headache.

A much greater potential problem with ESMTP. There is nothing that says
a UUCP network must be full-mesh. Even in the old days (or maybe especially
in the old days) there were a lot of leaf nodes and a small handful of
trunk nodes.( Well, towards the end, prior to the creation of UUNET, there
were actually a rather large handful of trunk nodes. :-)
Remembering that one big difference is that number of hops will have a
very minimal effect on time of delivery. A message that passed thru 20
machines may still get deliverd to the destination inbox in minutes as
opposed to the old days when it would likely have taken days to traverse
the network.

> And even more so if the
> misbehaving node cut from one side of the network could reappear
> from the other, which is one more thing for the policy to cover.

By agreement, all points of connection would terminate the offending node.
And, hopefully, trying to come back would not work even if attempted under
a different name. In any event, if Node "C" got disconnected for violating
the agreement and then attempted to connect again somewhere else using some
form of faked ID I expect a legal line would have been crossed. SPAMMERS
do what they do because under the current system there are no penalties.
They are unlikely to risk ruining that game by doing something that is
obviously a violation of the law.

>
> [...]
>
> >> Pseudographically speaking (and omitting the details) instead of
> >> doing it like:
>
> >> Alice -> MTA -> .. -> MTA -> Bob
>
> >> We do it either:
>
> >> Alice -> Bob
>
> >> Or, should there be no Internet connectivity at any given time
> >> (including the case of NAT):
>
> >> Alice -> Blobhost -> Bob
>
> >> Then, the messages are encrypted and signed, and every Alice, Bob
> >> and Charlie are free to establish their own whitelist, as well as
> >> rely on some sort of a Web of Trust to be done on top.
>
> > All of this is in use today. And yet, SPAM persists. Whitelists
> > only work if you already know everyone you will want to receive email
> > from and can trust.
>
> Which is no different to the proposed UUCP network.

In what way? "Alice's" host can not send email to "Bob's" host unless
they have an agreement to exchange email, either explcitly between them
or implicit in being a member of the network. Therefore when Bob gets
and email from Alice, if it came via the UUCP network, he has a much
greater expectation that it is a legitimate email from Alice and not a
forged peice of SPAM. I would say that baring the possible (and short-
term) exampls of "C" above that expectaion is greater than 99%.

>
> > With a system in place that makes spoofing addresses trivial
> > filtering at the user level is all but useless.
>
> This is addressed by the "the messages are encrypted and signed"
> requirement above.

Encrypted and signed would require you to know in advance every person you
were going to exchange email with. Or trust that the SPAMMER isn't going
to be allowed to put public keys on what evert he keyserver is. Oh yeah,
you also have to trust the keyserver. Explain to me again how this is
easier to admin and less complicated than the UUCP proposal. :-)

>
> > And filtering at the MTA level runs the risk of extremely high false
> > positives resulting in large numbers of missed emails and very little
> > likely reduction in SPAM.
>
> Well, to stress it out: my scheme above has no MTAs whatsoever.

Excuse me? All email coming into this department has to go to an MTA.
How would you propose sending it directly a user without it being handled
by MTA's? the users comoputers aren't even here all the time and don't
have fixed addesses either here or at their homes. How would you even
find them?

>
> > The other nice thing about my suggestion is that I am not suggesting
> > replacement of SMTP. Let the world go on as it has. Join a UUCP
> > network if you want.
>
> And the nice point about /my/ suggestion is that you can use the
> better maintained ESMTP software instead -- the rest being
> exactly the same.

I don't see that. to be honest I haven't looked much but a quick
look didn't reveal anything we were likely to be able to use here
that was ESMTP out of the box. UUCP has been around for decades.
How much more maintenance do you think it needs? How many latent
bugs do you think are still hiding in there? And administratively
I think UUCP is much easier to set up and run.

>
> (FTR, I've actually made two suggestions: one is to use ESMTP in
> a "closed" network, and the other is to abandon the traditional
> "routable" mail -- and thus MTAs, ESMTP, UUCP, etc. --
> altogether.)

I would love to hear how you propose to do your non-routable mail. Given
the problems we have now when, technically, only a small number of machines
should be moving email in the first place, how do you propose to stop this
if every PC in the world suddenly becomes an MTA (wether you like the use
of that term or not!)

>
> [...]
>
> > The proposed system creates a way for an individual who is willing to
> > play by the rules to run an email server of their own legitimately.
>
> FWIW, I'm loosely working on a solution to this exact problem.
> I'd welcome betatesters interested in configuring an ESMTPS
> implementation (and maintaining IPv6 connectivity.)
>
> > Especially useful if one only wishes to communicate with a small
> > group of people, perhaps researchers with common interests.
>
> ... However, my solution is intended to be "open," allowing
> routing to and from the Internet. (Should the addresses become
> known to the abusers, that is.)

Mine is too. I am not suggesting people disconnect from the SMTP system.
I am only proposing a system that can allow users to receive email from
selected other users with a near 100% expectation of veracity.

[Ivan Shmakov]

>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:

[...]

>>> UUCP is a protocol that requires a social connection between the
>>> people who are going to exchange email.

>> Not at all: it's the matter of policy, not protocol.

> Sorry, the confusion of the language. I didn't mean the UUCP
> protocol at the protocol level required a social connection, but the

> servers require it in order to exchange email. Joe random machine
> can not just send email to a UUCP node like he can to an SMTP MTA.
> The node has to be aware of his existence and have set up the
> necessary information for him to connect before email will be
> accepted.

That should really read "a typical UUCP node" and "a typical
SMTP MTA," respectively. I'm pretty sure that I /can/ configure
an UUCP node to accept email from anywhere.

[...]

>> Conversely, what could prevent me from starting an ESMTP network
>> with explicit trust between the nodes, requiring a photo ID
>> verification to join it?

> Nothing. The one difference I see between using UUCP and ESMTP (at
> least as I understand ESMTP) while individual agreements and
> information can be required using UUCP it would also be possible to
> have a network agreement by which you agree to accept other people's

> judgment of "trusted" and let UUCP email hop between nodes rather

> than being a strict point-to-point like SMTP/ESMTP is. Thus reducing
> the overhead and administration. But then, this was kind of implied
> when I mentioned people setting up "hubs". ESMTP, as I understand
> it, would require separate login information for every single site
> you wanted to exchange email with. This could become an
> administrative nightmare for anything but the smallest network.

First of all, -- ESMTP /allows/ for "routable" mail. So, Alice
can set up her MTA to accept mail from Bob's, and Bob can in
turn set up his MTA to accept mail from Charlie's, thus allowing
for Charlie's messages to reach Alice. And similarly in the
other direction. As soon as there's a proposal to start a /new/
ESMTP-based network, there's no reason not to "revise" the "good
old" point-to-point mode of ESMTP operation.

Moreover, given a network of A <-> B <-> C, DKIM (when properly
set up) makes it possible for a user at C to selectively reject
mail from B if it came there from A, -- just like Path:, but
with some strong cryptography behind.

One another point is that public key cryptography requires only
one "login" (or identifier) per node, the rest being the
"identifier to persona" binding, and one's trust to such
personae.

[...]

>>> "Some occasional"? Try the majority of current emails.

>> I'm yet to analyze my recent logs. Hopefully I'll post (probably to
>> news:comp.mail.misc) the results within the next few days.

> I use DNSBL's with our MTA. I personally still get 20 times as much
> SPAM as real email

I guess it's more or less the same here.

> and that is with personal procmail filtering. I am getting ready to
> try yet another anti-SPAM system but I have little hope of it being
> able to defeat the SPAMMERS. And, all of this still leaves the fact
> that even if you filter it from your mailbox, your network and MTA
> still had to waste the resource moving it around the world.

That's the case for procmail, not DNSBL, which leads to
rejection before actual DATA is sent.

> Much better to stop it at the originating node by not accepting it in
> the first place.

Perhaps. Though please note that the "originating node" may in
this case be a dedicated spambot. Or an unmaintained system.
Or a "compromised" one (as in: one which spambot have
successfully brute-forced.)

>>> Black lists have their problems, too. False positives.

>> Are there many? (But then, my systems currently do graylisting for
>> DNSBLed peers.)

> Brings up the old question we have discussed here. "How many valid
> email messages didn't you receive because of filtering?" How do you
> answer that question? Any false positives are too many.

AIUI, a "false positive" in the DNSBL (or IN PTR) case generally
means a misconfigured system at the other end. An early
rejection is likely to be properly reported to the sender, too.

[...]

>>> Actually, if everyone who controls a network would block outgoing
>>> port 25 traffic from everyone but legitimate MTA hosts most of the
>>> problem would go away. But after all these years we know that is
>>> not going to happen.

>> ... Unless a "new network" is started,

> A new network was started. INTERNET II. But a separate network will
> never catch on because too much stuff is already over here. My
> proposal runs on the existing infrastructure coexists with existing
> systems with little if any affect on the user community.

Yet it still /is/ a separate mail relay network. Surely, one
may choose to participate in either network, or in both at the
same time, but that doesn't make the newly proposed network any
less separate to the "ordinary" Internet Email.

[...]

>> which is the crux of the suggestion above. (With my point being
>> that the protocol is secondary to the policy.)

> Quite true. And the average email sysadmin has no say whatsoever in
> the policy in use on the current INTERNET.

But then, the policies in use in the Internet of today generally
forbid spam. For instance, at least one of the VPS providers
I've used threatened immediate service termination in the case
of spamming. The Internet network (as in: AS) operators
generally employ the same rules, even though they aren't
enforced all that often against residential customers' networks
(which is why these are routinely DNSBLed.)

> But, by overlaying this with a UUCP email network these email admins
> can take control of at least a small part of it. They would set the
> policy for their overlayed network.

It's the same whether done with UUCP, ESMTP, FTN, or otherwise.

[...]

>>> Whoever "C" is connected to cuts them off if they violate the
>>> agreement. Period. "C" is now out of the picture. If "C" cares
>>> they would have taken the steps necessary to prevent it. If they
>>> don't care, then Good Bye.

>> The first issue is that while the message is out of the agreement
>> between A and B, it may very well be in agreement between C and its
>> uplink. (Think of nodes belonging to different jurisdictions, for
>> instance.)

> You seem to have missed the point. There aren't different
> agreements. If "B" does not impose the same limits on "C" that he
> agreed to with "A", then "B" is in violation and gets cut off, which,
> in your example also cuts off "C".

That sounds much better, indeed. (Even though I still fail to
see anything specific to UUCP in that.)

> But the point is that unlike the current situation where everyone
> does as they please

I'd argue that it isn't quite the current situation.

> this network will have a set of rules. Call it an "Acceptable Use
> Policy" as that is a well understood concept by this point. It
> applies to anyone who wishes to connect to the network.

(And that's how FidoNet operates to this day, BTW.)

[...]

>>> The postmasters at "A" and "B" know exactly where the offending
>>> email originated.

>> Not at all: the data could be forged, unless somehow protected.

> Not likely. Using your example:

> "C" connects to "B" sends message. "B" creates the Path: header that

> says joeuser!C!B. He knows where it came from. "C" had to login

> using credentials not known by users, only the UUCP Admin.

My concern was that B could forge the message to appear as
coming from C. DKIM does a better job at validating whether a
message has passed a specific node or not.

[...]

>>> No, they terminate the node that originated the offending email.

>> The point is that it'd be the responsibility of the direct link of
>> that node, which may end up being unreachable at any given time.

> Don't understand this statement. Yes, it would be the responsibility
> of the node the offender is directly connected to, which could be a
> number of nodes. And, based on a legitimate complaint by any
> upstream nodes all nodes providing a connection to "C" would sever
> them.

... Unless one of them happens to be on a vacation, thus
requiring an action of his or her uplink to rectify the issue.

[...]

>> Yet the problem with meshes like this is that every single link is
>> someone's potential headache.

> A much greater potential problem with ESMTP.

Not at all, given that ESMTP links can be managed similarly to
UUCP ones.

> There is nothing that says a UUCP network must be full-mesh.

And neither is there anything saying that of an ESMTP network.

[...]

>> And even more so if the misbehaving node cut from one side of the
>> network could reappear from the other, which is one more thing for
>> the policy to cover.

> By agreement, all points of connection would terminate the offending
> node. And, hopefully, trying to come back would not work even if
> attempted under a different name. In any event, if Node "C" got
> disconnected for violating the agreement and then attempted to
> connect again somewhere else using some form of faked ID I expect a
> legal line would have been crossed.

So, the overall policy has to require some sort of an ID for
participation? Wouldn't that be quite an excessive a measure?

[...]

>>> All of this is in use today. And yet, SPAM persists. Whitelists
>>> only work if you already know everyone you will want to receive
>>> email from and can trust.

>> Which is no different to the proposed UUCP network.

> In what way? "Alice's" host can not send email to "Bob's" host

> unless they have an agreement to exchange email, either explicitly

> between them or implicit in being a member of the network. Therefore
> when Bob gets and email from Alice, if it came via the UUCP network,
> he has a much greater expectation that it is a legitimate email from

> Alice and not a forged piece of SPAM.

I'd reiterate my claim from above that ESMTP allows for
"routable" mail.

[...]

>>> With a system in place that makes spoofing addresses trivial
>>> filtering at the user level is all but useless.

>> This is addressed by the "the messages are encrypted and signed"
>> requirement above.

> Encrypted and signed would require you to know in advance every
> person you were going to exchange email with. Or trust that the
> SPAMMER isn't going to be allowed to put public keys on whatever the
> keyserver is.

Alternatively, one can trust a selected few, and then -- also
trust those trusted by these selected few, and so on.

For instance, Alice knows Bob's public key, and wishes to send
mail to Charlie. It's easy for her to obtain the Charlie's key
from a keyserver, but how does she verify it? -- obviously, by
checking Bob's signature on it! Now trusting that key, she
signs and sends a message for Charlie.

Conversely, Charlie also checks Bob's signature on the Alice's
key (wherever it's obtained from), and having it verified, can
verify the Alice's own signature.

... Which leads to the very same A -> B -> C scheme, only now
possible on top of "ordinary" Internet email.

> Oh yeah, you also have to trust the keyserver.

Well, replace the occurrences of "UUCP node operator" with
"keyserver operator," -- and the proposed UUCP network -- all of
a sudden! -- becomes a Public Key Infrastructure.

And the Web of Trust, as described above, doesn't have to be
"full mesh," either.

[...]

>>> And filtering at the MTA level runs the risk of extremely high
>>> false positives resulting in large numbers of missed emails and
>>> very little likely reduction in SPAM.

>> Well, to stress it out: my scheme above has no MTAs whatsoever.

> Excuse me? All email coming into this department has to go to an
> MTA. How would you propose sending it directly a user without it

> being handled by MTA's? The users computers aren't even here all the
> time and don't have fixed addresses either here or at their homes.

> How would you even find them?

The "fixed addresses" part is actually simple: there're a plenty
of dynamic DNS providers out there. (And as for the "aren't
even here" case, my scheme allowed for a Alice -> Blobhost ->
Charlie case.)

Yet indeed, should I've had all the details worked out, I'd
currently be busy implementing it.

... Basically, it all boils down to the resources part, and then
to the point of message size limit. Would you accept that 8 KiB
is a perfect limit for an email size? I'd argue that it is, for
it's possible for the "payload" part of a message to be
transferred (or not!) separately, from (say) an HTTP server.

So, instead of accepting some 10 .. 100 KiB (or more) spam
messages, one accepts what happens to be mere "pointers" to the
content itself, the latter being available from one or more of
locations that provide the respective service.

Now, the user can use the following criteria when filtering:

* is the pointer signed by a known and trusted party?

* is the content itself available from a known and trusted
party?

* (with some additional measures) is the content (as determined
by a message digest) already marked as inappropriate by a
known and trusted party?

And the "payload," however big, is now transferred to the user
"directly," rather than being routed through all the MTAs, -- or
not at all, should the pointer fail the checks set by the user.

[...]

>> And the nice point about /my/ suggestion is that you can use the
>> better maintained ESMTP software instead -- the rest being exactly
>> the same.

> I don't see that. To be honest I haven't looked much but a quick

> look didn't reveal anything we were likely to be able to use here
> that was ESMTP out of the box. UUCP has been around for decades.

The problem is that these were the decades before TLS was
conceived. Today, I'd hesitate to run pretty much anything,
unless with a sound encryption in place.

> How much more maintenance do you think it needs? How many latent
> bugs do you think are still hiding in there? And administratively I
> think UUCP is much easier to set up and run.

That'd depend largely on one's prior experience.

>> (FTR, I've actually made two suggestions: one is to use ESMTP in a
>> "closed" network, and the other is to abandon the traditional
>> "routable" mail -- and thus MTAs, ESMTP, UUCP, etc. -- altogether.)

> I would love to hear how you propose to do your non-routable mail.
> Given the problems we have now when, technically, only a small number
> of machines should be moving email in the first place, how do you
> propose to stop this if every PC in the world suddenly becomes an MTA

> (whether you like the use of that term or not!)

"Every PC in the world" has already became an "FTP server," --
thanks to BitTorrent. Doesn't yet seem quite like a disaster.
(Unless for RIAAs and MPAAs worldwide, that is.)

[Ivan Shmakov]

To support my argument, here are some configuration examples for
Exim, hopefully showing that ESMTP can indeed be set up to route
messages in UUCP-like manner.

Here I assume an already configured Exim instance, and cover
only the settings specific to the use of UUCP-like routing.
Also to note is that it's possible for the same Exim instance to
also operate as part of the "ordinary" ESMTP network, or be
completely isolated from it.


Routing mail to direct neighbors

This can be configured simply by listing the neighbors' DNS
names in hubbed_hosts, like (assuming that the mail is accepted
on one of the respective IP addresses):

bob.example.net
charlie.example.com

The configuration above will take precedence over the usual
routing based on DNS (MX) records.

Please note that using hubbed_hosts does /not/ automatically
allow indiscriminate relaying to the hosts listed. We will
enable relaying for the mail coming from direct neighbors later.


Routing mail to indirect nodes

Such routing requires prior processing of an UUCP-like routing
map, resulting in (indirect, direct) pairs to be put into
hubbed_hosts, like:

dave.example.com bob.example.net

The above will route mail to Dave's node via Bob's.


Accepting mail from direct neighbors

This can be done on the basis of IP addresses (with the
relay_from_hosts hostlist), yet my own practice is to employ TLS
and X.509 certificates (check https://cacert.org/ to get one,
signed by a party which at least /some/ trust, for free.)

Thus, we use a X.509 DN list (relay_tls_dn), like:

CN=bob.example.net
CN=charlie.example.com

The following check has to be added to the acl_check_rcpt ACL,
somewhere before the relaying is otherwise denied (e. g., right
after the relay_from_hosts check.)

accept
hosts = +relay_from_hosts_tls_mta
verify = certificate
condition = ${if exists{CONFDIR/relay_tls_dn} \
{${lookup {$tls_peerdn} \
lsearch {CONFDIR/relay_tls_dn} {yes} {no}}} \
{no}}

This may be somewhat indiscriminate in that it allows relaying
for /any/ mail (and not only the mail confined to the proposed
network) coming from these trusted hosts.

We may also require the validity of X.509 certificates for TLS
for the direct neighbors with the tls_verify_hosts setting.


Filtering considerations

The filtering can be done on the basis of Received: headers.
Namely, if the topmost such header mentions a direct neighbor,
it can be assumed that the message came from the proposed
network. Consider, e. g.:

Received: from bob.example.net ([2001:db8:1337::cafe])
by alice.example.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
...

Should the topmost header be found valid, the second-topmost one
can then be checked against the network map, and so on.

[Bill Gunshannon]

In article <87iovlm...@violet.siamics.net>,

Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>
> [...]
>
> >>> UUCP is a protocol that requires a social connection between the
> >>> people who are going to exchange email.
>
> >> Not at all: it's the matter of policy, not protocol.
>
> > Sorry, the confusion of the language. I didn't mean the UUCP
> > protocol at the protocol level required a social connection, but the
> > servers require it in order to exchange email. Joe random machine
> > can not just send email to a UUCP node like he can to an SMTP MTA.
> > The node has to be aware of his existence and have set up the
> > necessary information for him to connect before email will be
> > accepted.
>
> That should really read "a typical UUCP node" and "a typical
> SMTP MTA," respectively. I'm pretty sure that I /can/ configure
> an UUCP node to accept email from anywhere.

I didn't say you couldn't. But but you can't configure it to send
email to everywhere. And it isn't receiveing email that is the
problem it is all the systems currently able to send email that
have no business doing so.

Strong cryptography implies considerable administrative overhead. I
don't know about you but my job keeps me busy enough now. The idea is
to lighten the load by eliminating the need for me to have to try and
keep one step ahead of the SPAMMERS. (Actually we are lucky if we only
stay one step behind them!!)

>
> One another point is that public key cryptography requires only
> one "login" (or identifier) per node, the rest being the
> "identifier to persona" binding, and one's trust to such
> personae.

What keys do I use? Who holds them? Why should I trust them?

>
> [...]
>
> >>> "Some occasional"? Try the majority of current emails.
>
> >> I'm yet to analyze my recent logs. Hopefully I'll post (probably to
> >> news:comp.mail.misc) the results within the next few days.
>
> > I use DNSBL's with our MTA. I personally still get 20 times as much
> > SPAM as real email
>
> I guess it's more or less the same here.
>
> > and that is with personal procmail filtering. I am getting ready to
> > try yet another anti-SPAM system but I have little hope of it being
> > able to defeat the SPAMMERS. And, all of this still leaves the fact
> > that even if you filter it from your mailbox, your network and MTA
> > still had to waste the resource moving it around the world.
>
> That's the case for procmail, not DNSBL, which leads to
> rejection before actual DATA is sent.

Yes, but seems to handle very little. And they also seem to come
and go requiring constant updating of the config for the MTA.

>
> > Much better to stop it at the originating node by not accepting it in
> > the first place.
>
> Perhaps. Though please note that the "originating node" may in
> this case be a dedicated spambot. Or an unmaintained system.
> Or a "compromised" one (as in: one which spambot have
> successfully brute-forced.)

All of which cease to be doable in my model.

>
> >>> Black lists have their problems, too. False positives.
>
> >> Are there many? (But then, my systems currently do graylisting for
> >> DNSBLed peers.)
>
> > Brings up the old question we have discussed here. "How many valid
> > email messages didn't you receive because of filtering?" How do you
> > answer that question? Any false positives are too many.
>
> AIUI, a "false positive" in the DNSBL (or IN PTR) case generally
> means a misconfigured system at the other end. An early
> rejection is likely to be properly reported to the sender, too.

I don't think there can be a real "false positive" in a DNSBL. I was
thinking more along the lines of things like SpamAssasin. Rejects for
name/address mismatches happen constantly. Latest one here was a MicroSoft
Server (the University outsourced their email to MS making this a real
problem. it has been like this for 5 years and MS has done nothing to
fix it. probably doesn't even understand what the problem is.)
I have also seen it from AT&T systems and Verizon. And even ,mil sites
maintained by high paid contractors who do nothing but email.

Probably (I don't know what FTN is) but my proposal has low overhead,
little if any visible impact on the users and should reduce the workload
of the admin. Don't see the same as being true for ESMTP.

>
> [...]
>
> >>> Whoever "C" is connected to cuts them off if they violate the
> >>> agreement. Period. "C" is now out of the picture. If "C" cares
> >>> they would have taken the steps necessary to prevent it. If they
> >>> don't care, then Good Bye.
>
> >> The first issue is that while the message is out of the agreement
> >> between A and B, it may very well be in agreement between C and its
> >> uplink. (Think of nodes belonging to different jurisdictions, for
> >> instance.)
>
> > You seem to have missed the point. There aren't different
> > agreements. If "B" does not impose the same limits on "C" that he
> > agreed to with "A", then "B" is in violation and gets cut off, which,
> > in your example also cuts off "C".
>
> That sounds much better, indeed. (Even though I still fail to
> see anything specific to UUCP in that.)

Nothing except that the software already exists, has been integrated into
INTERNET Email systems for decades (it can even use @ addresses) and can
be set up with minimal effort.

>
> > But the point is that unlike the current situation where everyone
> > does as they please
>
> I'd argue that it isn't quite the current situation.

How is it not? I can setup an email server on a PC in my house and send
email anywhere (except boxes like mine which won't accept it, but, trust
me, I am in the minority.) ISP's have been informed of the problem and
the means to fix at least 90% of it. They choose not to. Reasons are:
a) they really don't care b) they are in cahoots with the SPAMMERS and
Zombie operators c) they are totally incompetent. Your choice.

>
> > this network will have a set of rules. Call it an "Acceptable Use
> > Policy" as that is a well understood concept by this point. It
> > applies to anyone who wishes to connect to the network.
>
> (And that's how FidoNet operates to this day, BTW.)
>
> [...]
>
> >>> The postmasters at "A" and "B" know exactly where the offending
> >>> email originated.
>
> >> Not at all: the data could be forged, unless somehow protected.
>
> > Not likely. Using your example:
>
> > "C" connects to "B" sends message. "B" creates the Path: header that
> > says joeuser!C!B. He knows where it came from. "C" had to login
> > using credentials not known by users, only the UUCP Admin.
>
> My concern was that B could forge the message to appear as
> coming from C.

Why on earth for? Assuming he is an admin like me he has much better
things to do with his time. And precious little of it to spare, anyway.
If he wants to cut "C" off the network all he really has to do is tell
the Admin at "C" that he is not going to handle his traffic anymore.
There is nothing in any of this that forces anyone to do anything other
than play by the rules if they agree to them and voluntarily join.

> DKIM does a better job at validating whether a
> message has passed a specific node or not.

Don't know what DKIM is but your example requires unethical and probably
illegal actions by a a sys admin. That can get you fired and could get
you arrested.

>
> [...]
>
> >>> No, they terminate the node that originated the offending email.
>
> >> The point is that it'd be the responsibility of the direct link of
> >> that node, which may end up being unreachable at any given time.
>
> > Don't understand this statement. Yes, it would be the responsibility
> > of the node the offender is directly connected to, which could be a
> > number of nodes. And, based on a legitimate complaint by any
> > upstream nodes all nodes providing a connection to "C" would sever
> > them.
>
> ... Unless one of them happens to be on a vacation, thus
> requiring an action of his or her uplink to rectify the issue.

You don't do this for a living, do you? What's a vacation? Do you
think any serious non-personal MTA is left unmanned for any noticable
period of time? Something like this is the least of your worries.

>
> [...]
>
> >> Yet the problem with meshes like this is that every single link is
> >> someone's potential headache.
>
> > A much greater potential problem with ESMTP.
>
> Not at all, given that ESMTP links can be managed similarly to
> UUCP ones.
>
> > There is nothing that says a UUCP network must be full-mesh.
>
> And neither is there anything saying that of an ESMTP network.

Um.. I think there is. I can think of no serious email system that
will handle email from a machine that allows relaying and if you are
running SMTP and not full-mesh then someone is relaying. Aren't the
RBL's still running?

>
> [...]
>
> >> And even more so if the misbehaving node cut from one side of the
> >> network could reappear from the other, which is one more thing for
> >> the policy to cover.
>
> > By agreement, all points of connection would terminate the offending
> > node. And, hopefully, trying to come back would not work even if
> > attempted under a different name. In any event, if Node "C" got
> > disconnected for violating the agreement and then attempted to
> > connect again somewhere else using some form of faked ID I expect a
> > legal line would have been crossed.
>
> So, the overall policy has to require some sort of an ID for
> participation? Wouldn't that be quite an excessive a measure?

One ID per node. Not per User. How do you think UUCP worked before
the INTERNET?

>
> [...]
>
> >>> All of this is in use today. And yet, SPAM persists. Whitelists
> >>> only work if you already know everyone you will want to receive
> >>> email from and can trust.
>
> >> Which is no different to the proposed UUCP network.
>
> > In what way? "Alice's" host can not send email to "Bob's" host
> > unless they have an agreement to exchange email, either explicitly
> > between them or implicit in being a member of the network. Therefore
> > when Bob gets and email from Alice, if it came via the UUCP network,
> > he has a much greater expectation that it is a legitimate email from
> > Alice and not a forged piece of SPAM.
>
> I'd reiterate my claim from above that ESMTP allows for
> "routable" mail.

But has more overhead than UUCP in order to accomplish the same thing.

>
> [...]
>
> >>> With a system in place that makes spoofing addresses trivial
> >>> filtering at the user level is all but useless.
>
> >> This is addressed by the "the messages are encrypted and signed"
> >> requirement above.
>
> > Encrypted and signed would require you to know in advance every
> > person you were going to exchange email with. Or trust that the
> > SPAMMER isn't going to be allowed to put public keys on whatever the
> > keyserver is.
>
> Alternatively, one can trust a selected few, and then -- also
> trust those trusted by these selected few, and so on.

Which is how UUCP would work. Only with less administrative overhead.

>
> For instance, Alice knows Bob's public key, and wishes to send
> mail to Charlie. It's easy for her to obtain the Charlie's key
> from a keyserver, but how does she verify it? -- obviously, by
> checking Bob's signature on it! Now trusting that key, she
> signs and sends a message for Charlie.

But this required action by the user. Most of the users I know have no
idea what PKA even is much less how to use it. And what of the case of
someone who you have never met or spoken to before? And that, to the
best of your knowledge, has no common contacts? What now?

>
> Conversely, Charlie also checks Bob's signature on the Alice's
> key (wherever it's obtained from), and having it verified, can
> verify the Alice's own signature.
>
> ... Which leads to the very same A -> B -> C scheme, only now
> possible on top of "ordinary" Internet email.

With a lot of additional work for the users. Do you know anyone who
munges their return address in order to "stop the SPAMMERS"? Do you
know how many times I have been contacted by members of my user community
to explain why they can't just hit Reply and send an email to someone?
I expect over 95% of email users are not IT people and probably over 80%
of them are computer illiterate.

>
> > Oh yeah, you also have to trust the keyserver.
>
> Well, replace the occurrences of "UUCP node operator" with
> "keyserver operator," -- and the proposed UUCP network -- all of
> a sudden! -- becomes a Public Key Infrastructure.

No, because I am not trusting the UUCP admin with any secret information.
And, he is not outside the scope of the email MTA. When you use PKA you
have two admins and servers to deal with the email and the keys. PKA has
been around for over a decade, too. Howcome it hasn't solved the problem?
Howcome noone is using it (well, outside of the government and they pay
a small fortune to run theirs.)

>
> And the Web of Trust, as described above, doesn't have to be
> "full mesh," either.
>
> [...]
>
> >>> And filtering at the MTA level runs the risk of extremely high
> >>> false positives resulting in large numbers of missed emails and
> >>> very little likely reduction in SPAM.
>
> >> Well, to stress it out: my scheme above has no MTAs whatsoever.
>
> > Excuse me? All email coming into this department has to go to an
> > MTA. How would you propose sending it directly a user without it
> > being handled by MTA's? The users computers aren't even here all the
> > time and don't have fixed addresses either here or at their homes.
> > How would you even find them?
>
> The "fixed addresses" part is actually simple: there're a plenty
> of dynamic DNS providers out there. (And as for the "aren't
> even here" case, my scheme allowed for a Alice -> Blobhost ->
> Charlie case.)

They are not reactive enough to handle constantly changing addresses.
And most real mailservers will reject email coming from them so you
suddenly find yourself with a very small network of email users.

>
> Yet indeed, should I've had all the details worked out, I'd
> currently be busy implementing it.
>
> ... Basically, it all boils down to the resources part, and then
> to the point of message size limit. Would you accept that 8 KiB
> is a perfect limit for an email size? I'd argue that it is, for
> it's possible for the "payload" part of a message to be
> transferred (or not!) separately, from (say) an HTTP server.

You can argue that all you want. But the fact is either you offer the
service your users want or spend your time explaining to them why not.
I just went thru this here, too. Student tried to email a 50MB file to
a faculty member and it got rejected here. He sent it to the University's
email system and it went thru. His question was "Why didn't it work on
our system?" Totally ignoring the question: "Why were you emailing a
50MB file?"

>
> So, instead of accepting some 10 .. 100 KiB (or more) spam
> messages, one accepts what happens to be mere "pointers" to the
> content itself, the latter being available from one or more of
> locations that provide the respective service.

I have enough experience to assure you users will not accept the idea.
We have a department webserver where people can put large items and
just email a URL: to the professor to get them. Trust me, they don't.
The continue to try and email 50MB attachements.

>
> Now, the user can use the following criteria when filtering:
>
> * is the pointer signed by a known and trusted party?
>
> * is the content itself available from a known and trusted
> party?
>
> * (with some additional measures) is the content (as determined
> by a message digest) already marked as inappropriate by a
> known and trusted party?
>
> And the "payload," however big, is now transferred to the user
> "directly," rather than being routed through all the MTAs, -- or
> not at all, should the pointer fail the checks set by the user.

Too much additional responsibility on the user. They are not interested.
They just want to send email. If your system is any less transparent than
what they use today, it will fail.

>
> [...]
>
> >> And the nice point about /my/ suggestion is that you can use the
> >> better maintained ESMTP software instead -- the rest being exactly
> >> the same.
>
> > I don't see that. To be honest I haven't looked much but a quick
> > look didn't reveal anything we were likely to be able to use here
> > that was ESMTP out of the box. UUCP has been around for decades.
>
> The problem is that these were the decades before TLS was
> conceived. Today, I'd hesitate to run pretty much anything,
> unless with a sound encryption in place.

Already thought about this. I haven't looked at the current implementations
of UUCP so they may have encryption built in, but even if they don't, it is
trivial to run anything over SSH today.

>
> > How much more maintenance do you think it needs? How many latent
> > bugs do you think are still hiding in there? And administratively I
> > think UUCP is much easier to set up and run.
>
> That'd depend largely on one's prior experience.

Well, of course it does. But I am talking about something to be done
by professional email system admins and private individuals who have
a desire to be professional email admins. How much more experience
will any of these peole have with the system your are proposing as
an alternative?

>
> >> (FTR, I've actually made two suggestions: one is to use ESMTP in a
> >> "closed" network, and the other is to abandon the traditional
> >> "routable" mail -- and thus MTAs, ESMTP, UUCP, etc. -- altogether.)
>
> > I would love to hear how you propose to do your non-routable mail.
> > Given the problems we have now when, technically, only a small number
> > of machines should be moving email in the first place, how do you
> > propose to stop this if every PC in the world suddenly becomes an MTA
> > (whether you like the use of that term or not!)
>
> "Every PC in the world" has already became an "FTP server," --
> thanks to BitTorrent. Doesn't yet seem quite like a disaster.
> (Unless for RIAAs and MPAAs worldwide, that is.)

And most serious network operators who block that crap. Forgetting the
fact that it is used primarily to perform illegal activities you also
have all the wasted bandwidth, which, contrary to popular belief, is not
free.

>
> [...]

[Ivan Shmakov]

>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:
>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>> Bill Gunshannon <bi...@server3.cs.scranton.edu> writes:

[...]

>> One another point is that public key cryptography requires only one
>> "login" (or identifier) per node, the rest being the "identifier to
>> persona" binding, and one's trust to such personae.

> What keys do I use? Who holds them?

Obviously, the private key is held by the other end of the link,
and the public one is, well, public.

> Why should I trust them?

... The parties you agreed to accept mail from (or send to)?

[...]

>> That's the case for procmail, not DNSBL, which leads to rejection
>> before actual DATA is sent.

> Yes, but seems to handle very little. And they also seem to come and
> go requiring constant updating of the config for the MTA.

I've got an impression that there're a handful of such lists
which are running for years now. (Though I haven't investigated
this issue much yet.)

[...]

>> Perhaps. Though please note that the "originating node" may in this
>> case be a dedicated spambot. Or an unmaintained system. Or a
>> "compromised" one (as in: one which spambot have successfully
>> brute-forced.)

> All of which cease to be doable in my model.

I'd argue that unmaintained systems are possible in any model.
And even more so for the "compromised" ones. (As in: "the users
won't do UUCP; they'd use Webmail you provide instead, and their
password will be not much stronger than 12345.")

Surely, the smaller the network, the less trouble they cause.
The point is that the Internet of today has so much MTAs that
even a negligible chance for one of them to become compromised
results in a considerable headache.

[...]

>> AIUI, a "false positive" in the DNSBL (or IN PTR) case generally
>> means a misconfigured system at the other end. An early rejection
>> is likely to be properly reported to the sender, too.

> I don't think there can be a real "false positive" in a DNSBL. I was
> thinking more along the lines of things like SpamAssasin. Rejects
> for name/address mismatches happen constantly. Latest one here was a
> MicroSoft Server (the University outsourced their email to MS making
> this a real problem. it has been like this for 5 years and MS has
> done nothing to fix it. probably doesn't even understand what the
> problem is.)

FWIW, I've just blocked 2a01:111:f400:f800::/53 at one of my
hosts, for being a constant source of spam.

[...]

>>> But, by overlaying this with a UUCP email network these email
>>> admins can take control of at least a small part of it. They would
>>> set the policy for their overlayed network.

>> It's the same whether done with UUCP, ESMTP, FTN, or otherwise.

> Probably (I don't know what FTN is)

FidoNet Technology Network. (That is, the body of FidoNet
standards currently in use.)

> but my proposal has low overhead, little if any visible impact on the
> users and should reduce the workload of the admin.

My guess is that joining FidoNet would imply even less work than
starting a whole new network. (Though again, depending on the
prior experience.)

> Don't see the same as being true for ESMTP.

I've just posted some example configuration for doing the things
as proposed. Doesn't look like too much trouble at all.

[...]

>>> But the point is that unlike the current situation where everyone
>>> does as they please

>> I'd argue that it isn't quite the current situation.

> How is it not? I can setup an email server on a PC in my house and
> send email anywhere (except boxes like mine which won't accept it,
> but, trust me, I am in the minority.)

ISTR that Google was in the league, thus making the "minority"
rather large, should the net amount of email traffic be
considered.

> ISP's have been informed of the problem and the means to fix at least
> 90% of it. They choose not to. Reasons are: a) they really don't
> care

Most probably they prefer to save money by not hiring a
responsible person for the job. Still, some ISPs are known to
block TCP port 25 outright.

> b) they are in cahoots with the SPAMMERS and Zombie operators c) they
> are totally incompetent. Your choice.

In the last two cases, the affected party could try to reach the
offender's uplink in turn, BTW. I'd expect for DNSBL operators
to give them a warm welcome, too.

[...]

>> DKIM does a better job at validating whether a message has passed a
>> specific node or not.

> Don't know what DKIM is but your example requires unethical and
> probably illegal actions by a a sys admin. That can get you fired
> and could get you arrested.

A successful prosecution would require evidence, and for this
case I fail to recall any kind of evidence strong enough to be
admissible in the court.

[...]

>>> Don't understand this statement. Yes, it would be the
>>> responsibility of the node the offender is directly connected to,
>>> which could be a number of nodes. And, based on a legitimate
>>> complaint by any upstream nodes all nodes providing a connection to
>>> "C" would sever them.

>> ... Unless one of them happens to be on a vacation, thus requiring
>> an action of his or her uplink to rectify the issue.

> You don't do this for a living, do you? What's a vacation? Do you
> think any serious non-personal MTA is left unmanned for any

> noticeable period of time?

I don't know what's meant by "serious" here, but I saw the cases
of MTAs serving a dozen or so of users being left unmanned for
around a week.

[...]

>>> There is nothing that says a UUCP network must be full-mesh.

>> And neither is there anything saying that of an ESMTP network.

> Um.. I think there is. I can think of no serious email system that
> will handle email from a machine that allows relaying and if you are
> running SMTP and not full-mesh then someone is relaying.

Someone's always relaying. Or do you mean "open" relays
specifically? (which I haven't implied.)

[...]

>> For instance, Alice knows Bob's public key, and wishes to send mail
>> to Charlie. It's easy for her to obtain the Charlie's key from a
>> keyserver, but how does she verify it? -- obviously, by checking
>> Bob's signature on it! Now trusting that key, she signs and sends a
>> message for Charlie.

> But this required action by the user. Most of the users I know have
> no idea what PKA even is much less how to use it. And what of the
> case of someone who you have never met or spoken to before? And
> that, to the best of your knowledge, has no common contacts? What
> now?

We already have a successful use case for public key
cryptography, namely: HTTPS. The problem with the approach not
working for email is a technical problem, and could very well be
resolved by technical means.

[...]

>>> Oh yeah, you also have to trust the keyserver.

>> Well, replace the occurrences of "UUCP node operator" with
>> "keyserver operator," -- and the proposed UUCP network -- all of a
>> sudden! -- becomes a Public Key Infrastructure.

> No, because I am not trusting the UUCP admin with any secret
> information.

Neither you do that in the case of a PKI keyserver. That's the
whole point of using /public/ key cryptography.

[...]

>> The "fixed addresses" part is actually simple: there're a plenty of
>> dynamic DNS providers out there. (And as for the "aren't even here"
>> case, my scheme allowed for a Alice -> Blobhost -> Charlie case.)

> They are not reactive enough to handle constantly changing addresses.
> And most real mailservers will reject email coming from them so you
> suddenly find yourself with a very small network of email users.

How does this apply to a discussion of starting a whole new
email network, even if one deployed parallel to the current one?
A novel system will require novel policies, and accepting email
from anyone, anywhere could very well be within them. (Even
though it is /not/ what I'm suggesting.)

[...]

>> So, instead of accepting some 10 .. 100 KiB (or more) spam messages,
>> one accepts what happens to be mere "pointers" to the content
>> itself, the latter being available from one or more of locations
>> that provide the respective service.

> I have enough experience to assure you users will not accept the
> idea. We have a department webserver where people can put large
> items and just email a URL: to the professor to get them. Trust me,
> they don't. The continue to try and email 50MB attachements.

... While the other admins simply configure their MTAs to save
any such MIME parts on an HTTPS server, while replacing them
with the resulting URIs in the transit mail.

[...]

>> And the "payload," however big, is now transferred to the user
>> "directly," rather than being routed through all the MTAs, -- or not
>> at all, should the pointer fail the checks set by the user.

> Too much additional responsibility on the user. They are not
> interested. They just want to send email. If your system is any
> less transparent than what they use today, it will fail.

Yes. But then, HTTPS is already sufficiently transparent to the
users, and I know why the problem couldn't be solved for email.

[...]

>> "Every PC in the world" has already became an "FTP server," --
>> thanks to BitTorrent. Doesn't yet seem quite like a disaster.
>> (Unless for RIAAs and MPAAs worldwide, that is.)

> And most serious network operators who block that crap. Forgetting
> the fact that it is used primarily to perform illegal activities

... Just like Usenet, you mean? (As in: *.binaries.*.)

> you also have all the wasted bandwidth, which, contrary to popular
> belief, is not free.

Now, consider the case of Alice and Bob, being in one network,
downloading a 1 GiB file from Charlie, which happens to reside
on the other side of the world. What of the following would you
consider the better use of bandwidth?

* Alice and Bob each download 1 GiB from Charlie via HTTP.

* Alice and Bob each download half a file via BitTorrent, while
"peering" the other half from each other.

P2P filesharing, if implemented properly, allows for
considerable bandwidth savings, not to mention the resilience to
the originator service outages, etc. Frankly, I'd consider for
a network operator to block HTTP to be much less insane a
measure than blocking BitTorrent.