UUCP: Is it alive?
Andrzej Adam Filip
I would like to learn about remaining areas in which UUCP is used and
reasons that make UUCP a good choice in these niches.
I have heard almost only about UUCP over high cost/satelite links for
email transfer such as inmarsat connections to ship.
URL(s):
http://www.inmarsat.com/
--
[pl2en: Andrew] Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
Victor Sudakov
> Does anybody use UUCP today?
Sure. We have several hundred UUCP customers (Tomsk, Russian
Federation). They are mostly legacy installations though.
http://www.tomsk.ru/cisa/price/#uucp
> I would like to learn about remaining areas in which UUCP is used and
> reasons that make UUCP a good choice in these niches.
For transfer of E-mail, mostly over dialup links. The advantages are:
1) UUCP can resume interrupted transfers; POP3 cannot.
2) UUCP customers have full control over local mailboxes, because they
receive mail for the entire domain.
We do not compress or batch UUCP mail, each message is a separate job.
Any more questions?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Andrzej Adam Filip
> Andrzej Adam Filip wrote:
>> Does anybody use UUCP today?
>
> Sure. We have several hundred UUCP customers (Tomsk, Russian
> Federation). They are mostly legacy installations though.
>
> http://www.tomsk.ru/cisa/price/#uucp
>
>> I would like to learn about remaining areas in which UUCP is used and
>> reasons that make UUCP a good choice in these niches.
>
> For transfer of E-mail, mostly over dialup links. The advantages are:
>
> 1) UUCP can resume interrupted transfers; POP3 cannot.
> 2) UUCP customers have full control over local mailboxes, because they
> receive mail for the entire domain.
>
> We do not compress or batch UUCP mail, each message is a separate job.
>
> Any more questions?
I wanted to find out is the following tricks are used:
a) filtering out invalid recipients *BEFORE* transfering mail via uucp
b) uucp grade assigment based on messages recipient/sender and message
content
Andrzej Adam Filip
> Andrzej Adam Filip <an...@onet.eu> wrote:
>> Does anybody use UUCP today?
>
> Yes.
>
>> I would like to learn about remaining areas in which UUCP is used and
>> reasons that make UUCP a good choice in these niches.
>
> Germany. Cheap exchange of large mail and news batches. High compression
> due to almost identical content in spam mails. In rural areas DSL is not
> always available, also the upstream is not that much faster than ISDN -
> and the spam-bounces going back that way take some time unless you
> compress them.
>
>> I have heard almost only about UUCP over high cost/satelite links for
>> email transfer such as inmarsat connections to ship.
>
> Take a look at
> From: Franz Georg =?ISO-8859-15?Q?K=F6hler?= <fgko...@openunix.de>
> Newsgroups: de.comm.uucp,de.comm.provider.suche,de.comm.provider.usenet
> Subject: <2006-07-13> Liste der UUCP-Anbieter im deutschsprachigen Raum
> Date: Sat, 30 Sep 2006 22:34:14 +0000 (UTC)
> Message-ID: <efmrd6$vgs$1...@news.internetdienste.de>
>
> Last-modified: 2006-07-13
> URL: http://www.hanau.net/usenet/txt/provide-uucp.txt
> which contains a list of UUCP provider in Germany (although the name
> suggests other countries too, there are no entries yet for e.g. Austria
> or Switzerland).
>
> Ralf
Is there any public "UUCP (mail) wishlist"?
Victor Sudakov
> I wanted to find out is the following tricks are used:
> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
We don't do this. Only rarely, a recipient can be blocked manually by
request of a customer.
We do recommend that customers' systems should not send bounces about
invalid recipients.
> b) uucp grade assigment based on messages recipient/sender and message
> content
We don't do this either.
Hauke Fath
> Victor Sudakov <v...@mpeks.no-spam-here.tomsk.su> writes:
>
> > Andrzej Adam Filip wrote:
> >> Does anybody use UUCP today?
> >
> > Sure. We have several hundred UUCP customers (Tomsk, Russian
> > Federation). They are mostly legacy installations though.
[...]
> I wanted to find out is the following tricks are used:
> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
> b) uucp grade assigment based on messages recipient/sender and message
> content
I am tempted to ask my UUCP "provider" - he is rather a one-man shop, a
left-over from the regional dependency of Individual Network e.V. when
it folded - about (a), since I found that at least a quarter of the UCE
I get is to random recipients @espresso, which is a catch-all.
But, same as Victor, he may see the UUCP setup as legacy, and may not be
willing to sink a few hours into it for installing a whitelist that can
be configured remotely. He runs a similar tool called "gup" for
subscribing to newsgroups.
Do you know of any ready-made solution for a (Sendmail based)
configurable whitelist?
hauke
--
Eine Linux User Group, um soziale Blockaden gegenüber Frauen
abzubauen? Da wäre ja ein Schwulengesangsverein noch produktiver.
{David Kastrup @ d.t.r}
Ramprasad
Andrzej Adam Filip wrote:
> Victor Sudakov <v...@mpeks.no-spam-here.tomsk.su> writes:
>
> > Andrzej Adam Filip wrote:
> >> Does anybody use UUCP today?
> >
> > Sure. We have several hundred UUCP customers (Tomsk, Russian
> > Federation). They are mostly legacy installations though.
Same here
and these are new installations.
> I wanted to find out is the following tricks are used:
> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
You would have a MTA , before the mail is sent to uucp spool. Reject
the mail at *that* level. That is the best way. I know that sometimes
may be a pain to implement , but it gives great results. Especially
today when more that half of the mail we receive are for wrong ids
Andrzej Adam Filip
> Andrzej Adam Filip wrote:
>> Victor Sudakov <v...@mpeks.no-spam-here.tomsk.su> writes:
>>
>> > Andrzej Adam Filip wrote:
>> >> Does anybody use UUCP today?
>> >
>> > Sure. We have several hundred UUCP customers (Tomsk, Russian
>> > Federation). They are mostly legacy installations though.
>
> Same here
Where is yours here? :-)
> and these are new installations.
>
>> I wanted to find out is the following tricks are used:
>> a) filtering out invalid recipients *BEFORE* transfering mail via
>> uucp
>
> You would have a MTA , before the mail is sent to uucp spool. Reject
> the mail at *that* level. That is the best way. I know that sometimes
> may be a pain to implement , but it gives great results. Especially
> today when more that half of the mail we receive are for wrong ids
I have meant rejections by MTA in replies to "RCPT TO:" command.
It makes host sending message to your host responsible for generating
bounce mail notification to the sender.
Andrzej Adam Filip
> Andrzej Adam Filip <an...@onet.eu> wrote:
>
>> Victor Sudakov <v...@mpeks.no-spam-here.tomsk.su> writes:
>>
>> > Andrzej Adam Filip wrote:
>> >> Does anybody use UUCP today?
>> >
>> > Sure. We have several hundred UUCP customers (Tomsk, Russian
>> > Federation). They are mostly legacy installations though.
>
> [...]
>
>> I wanted to find out is the following tricks are used:
>> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
>> b) uucp grade assigment based on messages recipient/sender and message
>> content
>
> I am tempted to ask my UUCP "provider" - he is rather a one-man shop, a
> left-over from the regional dependency of Individual Network e.V. when
> it folded - about (a), since I found that at least a quarter of the UCE
> I get is to random recipients @espresso, which is a catch-all.
>
> But, same as Victor, he may see the UUCP setup as legacy, and may not be
> willing to sink a few hours into it for installing a whitelist that can
> be configured remotely. He runs a similar tool called "gup" for
> subscribing to newsgroups.
>
> Do you know of any ready-made solution for a (Sendmail based)
> configurable whitelist?
Solutions using *static* list of valid addresses in relayed domain are
know for long. They require action of postmaster of SMTP2UUCP gateway.
As I understand for most UUCP sites list of valid email addresses is
"pretty stable".
I have not heard about ready tools for management of such list from
UUCP-only end of connection.
Andrzej Adam Filip
> Andrzej Adam Filip wrote:
>
>> I wanted to find out is the following tricks are used:
>> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
>
> We don't do this. Only rarely, a recipient can be blocked manually by
> request of a customer.
>
> We do recommend that customers' systems should not send bounces about
> invalid recipients.
Why should they waste their UUCP bandwidth for downloading such messages
in first place?
> [...]
Victor Sudakov
> > I wanted to find out is the following tricks are used:
> > a) filtering out invalid recipients *BEFORE* transfering mail via uucp
> > b) uucp grade assigment based on messages recipient/sender and message
> > content
> I am tempted to ask my UUCP "provider" - he is rather a one-man shop, a
> left-over from the regional dependency of Individual Network e.V. when
> it folded - about (a), since I found that at least a quarter of the UCE
> I get is to random recipients @espresso, which is a catch-all.
> But, same as Victor, he may see the UUCP setup as legacy, and may not be
> willing to sink a few hours into it for installing a whitelist that can
> be configured remotely. He runs a similar tool called "gup" for
> subscribing to newsgroups.
He would have to provide some kind of interface for the remote
editing of the access map. What kind of interface would you like to
have?
> Do you know of any ready-made solution for a (Sendmail based)
> configurable whitelist?
Our UUCP host runs Exim :)
Victor Sudakov
> > I wanted to find out is the following tricks are used:
> > a) filtering out invalid recipients *BEFORE* transfering mail via uucp
> You would have a MTA , before the mail is sent to uucp spool. Reject
> the mail at *that* level. That is the best way. I know that sometimes
There is absolutely no problem to reject at the MTA.
The problem is to figure out which recipients are desired and which
are not. You cannot do any LDAP lookup or recipient callout with a
remote UUCP system.
Holger Petersen
>> I wanted to find out is the following tricks are used:
>> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
>You would have a MTA , before the mail is sent to uucp spool. Reject
>the mail at *that* level.
How _if_ one gets all email via uucp as well as sending them to
different uucp-downlinks and some lokal recipients?
> That is the best way. I know that sometimes
>may be a pain to implement,
How would that be done with sendmail?
a) is there a global entry for 'procmail' to scan all incoming
mails?
b) I am working on a white-list feature for the mime-defang Milter.
c) I do have a black-list feature for that milter.
d) all (b) and (c) have to be edited by root...
Greetings, Holger
Andrzej Adam Filip
> "Ramprasad" <rampra...@gmail.com> writes:
>
>
>>> I wanted to find out is the following tricks are used:
>>> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
>
>>You would have a MTA , before the mail is sent to uucp spool. Reject
>>the mail at *that* level.
>
> How _if_ one gets all email via uucp as well as sending them to
> different uucp-downlinks and some lokal recipients?
In sendmail you can use FEATURE(`ldap_routing')
http://www.sendmail.org/m4/ldap_routing.html
It can be used with (classic) hash/dbm maps instead of LDAP lookups.
>> That is the best way. I know that sometimes
>>may be a pain to implement,
>
> How would that be done with sendmail?
>
> a) is there a global entry for 'procmail' to scan all incoming
> mails?
You can make sendmail pass messages for uucp link to procmail script and
make the script invoke uux.
[ mailer procmail in sendmail.mc with added F=m flag, otherwise the
script process every recipient separately ]
> b) I am working on a white-list feature for the mime-defang Milter.
> c) I do have a black-list feature for that milter.
> d) all (b) and (c) have to be edited by root...
--
Hauke Fath
> > But, same as Victor, he may see the UUCP setup as legacy, and may not be
> > willing to sink a few hours into it for installing a whitelist that can
> > be configured remotely. He runs a similar tool called "gup" for
> > subscribing to newsgroups.
>
> He would have to provide some kind of interface for the remote
> editing of the access map.
Gup lets you send a list of newsgroups that you want to {,un}subscribe,
and essentially maintains a subscription list for the batcher on the
provider's machine. You authenticate by adding a plaintext UID and
password, which is fine since this is between two neighbouring UUCP
systems, only.
>What kind of interface would you like to have?
An appropriate interface would allow me to request a copy of the current
whitelist, and add/remove entries by control mails. If you want to get
fancy, pgp-sign the mail.
Victor Sudakov
> > > But, same as Victor, he may see the UUCP setup as legacy, and may not be
> > > willing to sink a few hours into it for installing a whitelist that can
> > > be configured remotely. He runs a similar tool called "gup" for
> > > subscribing to newsgroups.
> >
> > He would have to provide some kind of interface for the remote
> > editing of the access map.
> Gup lets you send a list of newsgroups that you want to {,un}subscribe,
> and essentially maintains a subscription list for the batcher on the
> provider's machine. You authenticate by adding a plaintext UID and
> password, which is fine since this is between two neighbouring UUCP
> systems, only.
I used GUP once, it had a Web interface.
> >What kind of interface would you like to have?
> An appropriate interface would allow me to request a copy of the current
> whitelist, and add/remove entries by control mails. If you want to get
> fancy, pgp-sign the mail.
I think most our customers are not technically savvy enough to do this.
Nobody has ever requested such a feature.
Victor Sudakov
> >
> >> I wanted to find out is the following tricks are used:
> >> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
> >
> > We don't do this. Only rarely, a recipient can be blocked manually by
> > request of a customer.
> >
> > We do recommend that customers' systems should not send bounces about
> > invalid recipients.
> Why should they waste their UUCP bandwidth for downloading such messages
> in first place?
In fact, they have no choice.
If such a feature (ability to remotely edit whitelists) were included
into some popular UUCP client package, it would be possible. But
nowadays nobody is going to implement this.
Victor Sudakov
> Does anybody use UUCP today?
And if your customers still use UUCP, what software packages do they use?
Andrzej Adam Filip
> Andrzej Adam Filip wrote:
>> >
>> >> I wanted to find out is the following tricks are used:
>> >> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
>> >
>> > We don't do this. Only rarely, a recipient can be blocked manually by
>> > request of a customer.
>> >
>> > We do recommend that customers' systems should not send bounces about
>> > invalid recipients.
>
>> Why should they waste their UUCP bandwidth for downloading such messages
>> in first place?
>
> In fact, they have no choice.
>
> If such a feature (ability to remotely edit whitelists) were included
> into some popular UUCP client package, it would be possible. But
> nowadays nobody is going to implement this.
With no more than 3-5 "change request" per client per year it could be
maintained "manually" by provider.
Is it a "no option" for you/your outfit?
Victor Sudakov
> >> >
> >> >> I wanted to find out is the following tricks are used:
> >> >> a) filtering out invalid recipients *BEFORE* transfering mail via uucp
> >> >
> >> > We don't do this. Only rarely, a recipient can be blocked manually by
> >> > request of a customer.
> >> >
> >> > We do recommend that customers' systems should not send bounces about
> >> > invalid recipients.
> >
> >> Why should they waste their UUCP bandwidth for downloading such messages
> >> in first place?
> >
> > In fact, they have no choice.
> >
> > If such a feature (ability to remotely edit whitelists) were included
> > into some popular UUCP client package, it would be possible. But
> > nowadays nobody is going to implement this.
> With no more than 3-5 "change request" per client per year it could be
> maintained "manually" by provider.
Is this your estimate? Well, with 1000 customers it would make 8-13
change requests daily.
> Is it a "no option" for you/your outfit?
Several requests daily is already a good reason to think of some
automation.
Ed Carp
>>> If such a feature (ability to remotely edit whitelists) were included
>>> into some popular UUCP client package, it would be possible. But
>>> nowadays nobody is going to implement this.
>
>> With no more than 3-5 "change request" per client per year it could be
>> maintained "manually" by provider.
>
> Is this your estimate? Well, with 1000 customers it would make 8-13
> change requests daily.
>
>> Is it a "no option" for you/your outfit?
>
> Several requests daily is already a good reason to think of some
> automation.
Fetch the file remotely via UUCP, edit it locally, then UUCP it back up to the
server.
Victor Sudakov
I have no doubt that technically it is possible, but please read the
first paragraph of the quote.
Andrzej Filip http://anfi.homeunix.net/
As I understand something very similar has been implemented already by
some tools: accepting *signed* configuration files via email
(after signature verification)
--
[pl>en: Andrew] Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
Before You Ask: http://anfi.homeunix.net/sendmail/B4UAsk-Sendmail.html
http://anfi.homeunix.net/sendmail/ [orkut,linkedin,xing]
Victor Sudakov
> >
> >> >>> If such a feature (ability to remotely edit whitelists) were included
> >> >>> into some popular UUCP client package, it would be possible. But
> >> >>> nowadays nobody is going to implement this.
> >> >
> >> >> With no more than 3-5 "change request" per client per year it could be
> >> >> maintained "manually" by provider.
> >> >
> >> > Is this your estimate? Well, with 1000 customers it would make 8-13
> >> > change requests daily.
> >> >
> >> >> Is it a "no option" for you/your outfit?
> >> >
> >> > Several requests daily is already a good reason to think of some
> >> > automation.
> >
> >> Fetch the file remotely via UUCP, edit it locally, then UUCP it back
> >> up to the server.
> >
> > I have no doubt that technically it is possible, but please read the
> > first paragraph of the quote.
> As I understand something very similar has been implemented already by
> some tools: accepting *signed* configuration files via email
> (after signature verification)
I don't think any signing or verification is necessary. The remote
configuration feature does not have to be more secure than the UUCP
link itself. We do not require any additional security mechanisms for
the customer to upload sieve mail filters, edit server side rules etc,
do we?
The problem is, who is going to implement this functionality into UUCP
client software (yes, for Windows please).
Andrzej Filip http://anfi.homeunix.net/
> Andrzej Filip http://anfi.homeunix.net/ wrote:
>> >
>> >> >>> If such a feature (ability to remotely edit whitelists) were included
>> >> >>> into some popular UUCP client package, it would be possible. But
>> >> >>> nowadays nobody is going to implement this.
>> >> >
>> >> >> With no more than 3-5 "change request" per client per year it could be
>> >> >> maintained "manually" by provider.
>> >> >
>> >> > Is this your estimate? Well, with 1000 customers it would make 8-13
>> >> > change requests daily.
>> >> >
>> >> >> Is it a "no option" for you/your outfit?
>> >> >
>> >> > Several requests daily is already a good reason to think of some
>> >> > automation.
>> >
>> >> Fetch the file remotely via UUCP, edit it locally, then UUCP it back
>> >> up to the server.
>> >
>> > I have no doubt that technically it is possible, but please read the
>> > first paragraph of the quote.
>
>> As I understand something very similar has been implemented already by
>> some tools: accepting *signed* configuration files via email
>> (after signature verification)
>
> I don't think any signing or verification is necessary. The remote
> configuration feature does not have to be more secure than the UUCP
> link itself. We do not require any additional security mechanisms for
> the customer to upload sieve mail filters, edit server side rules etc,
> do we?
What kind of protections do you use to avoid one customer changing
another customer configuration? [let it be archived for future readers]
> The problem is, who is going to implement this functionality into UUCP
> client software (yes, for Windows please).
IMHO in initial version simple text file would be sufficient.
[ one email address per line and some convention for comments ]
Victor Sudakov
[dd]
> >
> >> As I understand something very similar has been implemented already by
> >> some tools: accepting *signed* configuration files via email
> >> (after signature verification)
> >
> > I don't think any signing or verification is necessary. The remote
> > configuration feature does not have to be more secure than the UUCP
> > link itself. We do not require any additional security mechanisms for
> > the customer to upload sieve mail filters, edit server side rules etc,
> > do we?
> What kind of protections do you use to avoid one customer changing
> another customer configuration? [let it be archived for future readers]
The same protections which prevent one customer from downloading or
uploading another customer's mail or files: the UUCP passwords and
the builtin file transfer control features (remote-receive etc).
After all, the configuration change request could be just a uux job.
> > The problem is, who is going to implement this functionality into UUCP
> > client software (yes, for Windows please).
> IMHO in initial version simple text file would be sufficient.
> [ one email address per line and some convention for comments ]
OK, what client package should we modify?