ietf-asrg
[Top] [All Lists]

Re: [Asrg] Ban the bounce; improved challenge-response systems

2003-04-06 13:11:39
On Sun, 6 Apr 2003 11:04:45 -0400 
Jim Youll <jim(_at_)media(_dot_)mit(_dot_)edu> wrote:
At 7:34 -0700 4/6/03, Chuq Von Rospach wrote:
On Sunday, April 6, 2003, at 05:30 AM, Hallam-Baker, Phillip wrote:

so UUCP is still in fair use but clearly a minority.

A minority of traffic and addresses to be sure, however the total number
of humans behind such links can probably be assumed to be in the tens if
not hundreds of millions.  When numbers get large its easy to play the
percentage game while forgetting that very small percentages are still
large numbers.

Is it really a good idea that all mail products should have to handle
it - and design anti-spam or other things around it?

We are, in general, geeks, and so can safely deal with abstractions
which can't and shouldn't be exposed to JoeSixpack end-users.  

Email consists of two layers: payloads and transports.  

Payloads are currently defined by RFC 2822 and the various MIME RFCs
(plus other more minor bits like 2369 etc).  Transports carry payloads
about and are (primarily) at this point represented by SMTP and UUCP
(there are others) and are covered by RFCs 281, 976 and others that slip
my cranium at this point.

Its an easy and often tempting logical escape to try and conflate the
two abstractions into one, to consider the payload and the transport as
siamese twins that are ineluctably codependent.  However, that's not
current reality, and doesn't match (in general) with any of the standard
methods of protocol analysis and design.  Payload and transport are
fundamentally different -- this is one of the HUGE simplifications that
TCP/IP added to the networking arena.

Do you design your refrigerator for how many wheels are on the trucks
that will deliver it to your house, or do you design a refrigerator
which is a good fridge and which can be easily (generically) transported
to their consumers, and then design trucks which are good trucks and
which can easily transport generic payloads, like those fridges and
others to their consumers?

Might it make more sense from a design standpoint for UUCP endpoints
to be gatewayed through something that talks current protocols on one
side, and UUCP on the other? I have to think that most everyone who's
using UUCP could probably find a host (probably owns one, perhaps at
the home research institution that they contact via the satphone) that
would serve this function. Even in the developing world, there are
linkages to supportive "other" institutions that could help in a
transitional time.

That is precisely what happens now.  Necessarily from the DNS, MX, and
SMTP consistency point there needs to be a delivery target that acts as
the interface for mail routing.  Sometimes its a volunteer operation,
sometimes a professional service (for a while all of Congo hung off a
single 486-33 that was run out of a teen-agers back bedroom in Atlanta).

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw(_at_)kanga(_dot_)nu               He lived as a devil, eh?           
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>