warning: connect to transport uucp : Connection refused
Maria Blackmore
Hi,
I have recently upgraded a mail server here to postfix, it's purpose in
life is to service virtual mail domains, some of these being uucp based
this is working really well so far, except for the error message in the
subject line
this is what is in master.cf referring to it:
uucp unix - - n - - pipe
flags=F user=uucp argv=/usr/bin/uux -r -n -z -a$sender -
$nexthop!rmail ($recipient)
one thing I thought of is whether there is meant to be a new line after
"pipe", but removing it has no effect
after a variety of tests, it seems that anything that tries to use pipe to
form a transport simply doesn't work, giving the error "Connection
refused"
the command set for argv works fine when executed manually
i checked that the socket for uucp exists in /var/spool/postfix/private,
and it does:
srw-rw-rw- 1 postfix postfix 0 Jul 24 15:07 uucp
pipe, the daemon, lives in /usr/local/postfix:
-rwxr-xr-x 1 root root 395032 May 18 18:51 pipe
(postconf -n below :)
what else could be causing this? there are now over a dozen messages
waiting in the queue having been deferred due to this transport being
unavailable, and I cannot think of anything left to try.
thanks everyone
Maria Blackmore
PS: this is the output of postconf -n:
2bounce_notice_recipient = postmaster
access_map_reject_code = 550
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_percent_hack = yes
allow_untrusted_routing = no
always_bcc =
append_at_myorigin = yes
append_dot_mydomain = yes
bounce_notice_recipient = postmaster
bounce_size_limit = 51200
command_directory = /usr/sbin
command_time_limit = 1000
daemon_directory = /usr/local/postfix
daemon_timeout = 18000
debug_peer_level = 2
default_database_type = hash
default_destination_concurrency_limit = 10
default_destination_recipient_limit = 50
default_process_limit = 50
default_transport = smtp
delay_notice_recipient = postmaster
deliver_lock_attempts = 5
deliver_lock_delay = 5
duplicate_filter_limit = 900
empty_address_recipient = postmaster
error_notice_recipient = postmaster
fallback_relay =
fork_attempts = 5
fork_delay = 1
forward_path = $home/.forward
hash_queue_depth = 2
header_checks = regexp:/etc/postfix/unwanted
header_size_limit = 102400
home_mailbox =
hopcount_limit = 30
ignore_mx_lookup_error = no
inet_interfaces = all
initial_destination_concurrency = 2
invalid_hostname_reject_code = 501
ipc_idle = 100
ipc_timeout = 3600
line_length_limit = 2048
local_destination_concurrency_limit = 2
local_destination_recipient_limit = 1
local_recipient_maps = $alias_maps unix:passwd.byname
local_transport = local
luser_relay = postmaster
mail_name = BNS Postfix
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mail_version = 19991231
maps_rbl_domains =
maps_rbl_reject_code = 550
masquerade_domains = $mydomain, bnsnet.co.uk
masquerade_exceptions = root
max_idle = 100
max_use = 100
maximal_backoff_time = 7200
maximal_queue_lifetime = 5
message_size_limit = 10485760
minimal_backoff_time = 900
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
mail.$mydomain, www.$mydomain, ftp.$mydomain
mydomain = bucks.net
myhostname = babylon.bucks.net
mynetworks = 195.112.36.0/24, 195.112.37.0/24, 195.112.45.0/24,
195.149.10.0/24, 195.149.11.0/24, 127.0.0.0/8
myorigin = $mydomain
notify_classes = resource,software
prepend_delivered_header = command, file, forward
process_id_directory = pid
program_directory = /usr/local/postfix
qmgr_message_active_limit = 1000
qmgr_message_recipient_limit = 1000
queue_directory = /var/spool/postfix
queue_minfree = 0
queue_run_delay = 900
recipient_delimiter =
reject_code = 550
relay_domains = hash:/etc/postfix/secondmx
relay_domains_reject_code = 550
relocated_maps = hash:/etc/postfix/relocated
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_connect_timeout = 600
smtp_data_done_timeout = 600
smtp_data_init_timeout = 120
smtp_data_xfer_timeout = 180
smtp_destination_concurrency_limit = 10
smtp_destination_recipient_limit = $default_destination_recipient_limit
smtp_helo_timeout = 300
smtp_mail_timeout = 300
smtp_quit_timeout = 300
smtp_rcpt_timeout = 300
smtp_skip_4xx_greeting = no
smtp_skip_quit_response = yes
smtpd_banner = $myhostname ESMTP $mail_name, Welcome to Bucks Net
Services!
smtpd_client_restrictions =
smtpd_error_sleep_time = 5
smtpd_etrn_restrictions = permit_mynetworks
smtpd_hard_error_limit = 100
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname,
reject_unknown_hostname
smtpd_recipient_limit = 300
smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains,
reject_unknown_sender_domain
smtpd_soft_error_limit = 10
stale_lock_time = 600
sun_mailtool_compatibility = no
swap_bangpath = yes
transport_maps = hash:/etc/postfix/transport
transport_retry_time = 60
trigger_timeout = 10
unknown_address_reject_code = 450
unknown_client_reject_code = 450
unknown_hostname_reject_code = 450
virtual_maps = hash:/etc/postfix/virtual
--
Maria Blackmore
Linux Systems Administrator, Bucks Net Services
Maria Blackmore
> Historicly UUCP transport happens through serial ports
> over modems, but your config looks like it takes
> advantage of UUCP over TCP.
The config delivers the mail (hopefully!) to the machines own uucp system
to be collected by a customer, to do this it uses uux and a variety of
options which make more sense than I expected to ... if i do it manually
though, it works
> Maybe the refused connection
> comes from the UUCP service being disabled at the port
> level in inetd.conf level on your machine or the
> neighboring machine?
I wish it was this simple, but the machine itself listens for uucp, being
as this is how customers can connect to collect mail
> If UUCP transport over TCP is not
> intended, then your main.cf could benefit from this entry
>
> transport_maps = hash:/etc/postfix/transport
it already has this line, to the letter :)
> Where transport would contain something like this:
>
> # This stuff goes through myhost!oneuucphost!...
> oneuucphost uucp:oneuucphost
> oneuucphost.uucp uucp:oneuucphost
> oneuucphost.their.virt.domain.com uucp:oneuucphost
hmm .. this is an example line from the transport file ...
tst-uucp.bucks.net uucp : tst-uucp
where tst-uucp is the account name you connect with remotely
to be honest, I have no idea if this is correct, but it sounds sane to me
because otherwise, how would the uucp system on the machine know what to
do with it?
> More is likely needed, but this could be a useful start. Of
> course, don't forget to postmap the transport file after
> editing it, and reload postfix, if you're in a hurry.
I wrote a make file to keep it all up to date, being lazy :)
Kevin Cosgrove
Historicly UUCP transport happens through serial ports
over modems, but your config looks like it takes
advantage of UUCP over TCP. Maybe the refused connection
comes from the UUCP service being disabled at the port
level in inetd.conf level on your machine or the
neighboring machine? If UUCP transport over TCP is not
intended, then your main.cf could benefit from this entry
transport_maps = hash:/etc/postfix/transport
Where transport would contain something like this:
# This stuff goes through myhost!oneuucphost!...
oneuucphost uucp:oneuucphost
oneuucphost.uucp uucp:oneuucphost
oneuucphost.their.virt.domain.com uucp:oneuucphost
More is likely needed, but this could be a useful start. Of
course, don't forget to postmap the transport file after
editing it, and reload postfix, if you're in a hurry.
G'luck....
Kevin Cosgrove
> The config delivers the mail (hopefully!) to the machines own uucp system
> to be collected by a customer, to do this it uses uux and a variety of
> options which make more sense than I expected to ... if i do it manually
> though, it works
Are you saying that you can run uux manually on a message
and get email into the /var/spool/uucp/tst-uucp C. and D.
directories for that message? Further, are you saying
that postfix won't deliver the mail using the same uux
command? Could you run postfix with extra verbosity
turned on and figure out what's going on from postfix's
maillog?
> I wish it was this simple, but the machine itself listens for uucp, being
> as this is how customers can connect to collect mail
So your customers are coming in over ethernet on the uucp
port, right? I'm a old UUCP "customer" and I dial-up my
UUCP neighbors in the traditional way.
> hmm .. this is an example line from the transport file ...
>
> tst-uucp.bucks.net uucp : tst-uucp
>
> where tst-uucp is the account name you connect with remotely
Actually, tst-uucp is the UUCP name of the remote host
connecting to your host. The above config would not pass
addresses like myhost!tst-uucp!... nor would it pass
som...@tst-uucp.uucp. Rather, these messages could be
trying to route through your default transport/system
> to be honest, I have no idea if this is correct, but it sounds sane to me
> because otherwise, how would the uucp system on the machine know what to
> do with it?
The above could be correct, with the possibilities of the
incomplete stuff I mentioned above. But, it must agree
with your UUCP config and that of your UUCP neighbors.
That might be a little off-topic, and the config for that
could be living in /etc/uucp/ on your Linux system -- it
is there on my Mandrake sys. I don't think this is the
default location for Taylor UUCP tho.
> I wrote a make file to keep it all up to date, being lazy :)
My setup is simple enough that an RPM subpackage of the
uucp RPM does what I need, being lazy too. :-)
Cheers....
Maria Blackmore
> > to be collected by a customer, to do this it uses uux and a variety of
> > options which make more sense than I expected to ... if i do it manually
> > though, it works
>
> Are you saying that you can run uux manually on a message
> and get email into the /var/spool/uucp/tst-uucp C. and D.
> directories for that message? Further, are you saying
> that postfix won't deliver the mail using the same uux
> command?
This is exactly it, yes if I run uux manually with the parameters that
would be parsed in by postfix, it appears in /var/spool/uucp/tst-uucp
instantly (in C. and D.) postfix reports cannot send to transport uucp
due to connection refused. On the other hand, it does the same with any
pipe based transport ... eg I popped "cat >> /root/test" into the command
for a new transport i created called test, which will append stdin to that
file ... still the same error!
> Could you run postfix with extra verbosity
> turned on and figure out what's going on from postfix's
> maillog?
I have been wanting to, but the mail server handles a vaste amount of mail
with huge logs ... I decided it would be best to wait until the weekend
when the mail level drops hugely
> > I wish it was this simple, but the machine itself listens for uucp, being
> > as this is how customers can connect to collect mail
> So your customers are coming in over ethernet on the uucp
> port, right? I'm a old UUCP "customer" and I dial-up my
> UUCP neighbors in the traditional way.
this is right, yes ... and this works too .. woo! the uucp config works
fine, and all I did was scp it over :)
> > hmm .. this is an example line from the transport file ...
> >
> > tst-uucp.bucks.net uucp : tst-uucp
> >
> > where tst-uucp is the account name you connect with remotely
>
> Actually, tst-uucp is the UUCP name of the remote host
> connecting to your host. The above config would not pass
> addresses like myhost!tst-uucp!... nor would it pass
> som...@tst-uucp.uucp. Rather, these messages could be
> trying to route through your default transport/system
*nod* this is the idea ... mail to tst-uucp.bucks.net is passed to the
remote user tst-uucp to be delivered locally on whatever machine connects
this is right, isn't it? *crosses fingers*
thanks for your reply! :)
Wietse Venema
>
> Hi,
>
> I have recently upgraded a mail server here to postfix, it's purpose in
> life is to service virtual mail domains, some of these being uucp based
>
> this is working really well so far, except for the error message in the
> subject line
>
> this is what is in master.cf referring to it:
>
> uucp unix - - n - - pipe
> flags=F user=uucp argv=/usr/bin/uux -r -n -z -a$sender -
> $nexthop!rmail ($recipient)
> after a variety of tests, it seems that anything that tries to use pipe to
> form a transport simply doesn't work, giving the error "Connection
> refused"
"connect to transport uucp: Connection refused" means that the
Postfix master process is not listening on the UNIX-domain socket
in /var/spool/postfix/private/uucp, or that you're running the
Postfix queue manager on a different machine than the master.
Wietse
Postfix List
mb> I have been wanting to, but the mail server handles a vaste amount of mail
mb> with huge logs ... I decided it would be best to wait until the weekend
mb> when the mail level drops hugely
Good idea.
mb> *nod* this is the idea ... mail to tst-uucp.bucks.net is passed to the
mb> remote user tst-uucp to be delivered locally on whatever machine connects
"remote user" is really "uucp host" and "whatever
machine" connecting via uucp must identify itself
identically as that uucp host, including password,
etc. But, from what you've said, once mail gets
into the uucp queue, it goes where it's supposed to.
It sounds like the only badness you're experiencing is
that you can't get postfix to handoff mail via uux.
In my mainly uucp setup, all I had to do is to set
default_transport = uucp and relayhost = mainuucpneighbor
All the rest of my postfix uucp outgoing config is in the
transport file (I already send a snip of that).
Without some of the maillog on a failing uucp attempt,
I'm stumped. Sorry...
Maria Blackmore
Hi,
for anyone interested, I have managed to track down what was causing this
by copying the config to another machine and enabling debug there, it
would appear that whatever parses the transports map doesn't strip white
space from either side of the transport and next hop that is set.
all the entries in the transports file had "uucp : wheretogo" on the RHS,
with the transport and destination being split at the colon, meaning that
it was actually trying to deliver to a transport called "uucp " which
obviously doesn't exist and can't actually be made to.
thanks for the replies, and for anyone interested, the server handles mail
for around 1300 users including pop3, imap and uucp collection, and I have
yet to see the load rise above 0.05. the machine itself is a Celeron 366
with 128Mb memory