Re: telnet on local LAN question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2011-08-18 at 21:05 -0700, Paul Allen Newell wrote:
> Part of trying to get mail / mailx running on my Linux boxes to send 
> mail to pnewell@xxxxxxxxxx involved using telnet as a test. They
> wanted me to use port 587 per their online docs. To get mail to work,
> I had to edit sendmail.mc to understand port 587.
>  
> So, I can type:
> +++
> telnet MX-LB--1.SRV.cs.cmu.edu 587
> +++
> 
> and it works. I presume that I don't have to edit anything to let
> telnet know about 587 is that its their end that is going to determine
> whether they will accept the telnet and they are listening on 587.
>
> Yes, I did try telnet <name> 587 to confirm that it doesn't work as my
> boxes know nothing about 587 above and beyond the config in
> sendmail.mc for mail / mailx.

They have a mail server listening on port 587, and if it's working and
accepting connections from you, you should be able to simply

 telnet servername portnumber

Just like you've done with your own mail servers, or any other server
that can be probed using telnet.  There's nothing for you to configure,
as far as trying to telnet to it.  You've done all you need to, and can
do, by passing the port number to the telnet client, along with the
address.

However, gotchas may be that /that/ server may not give a textual
response to being queried.  I don't know that protocol, it could be one
that only accepts submissions, and responses come out from somewhere
else.  Also, there would be the possibility that their server isn't
allowing connections from your IP.

> I can also telnet <name> 22 and see that it hooks up to port 22 (ssh),
> though it is utterly useless.
> 
> Why would I need to install a telnet server

Only if you wanted an unsecure command line interface to that computer.
Your telnet client is completely independent from having any telnet
server on your box.

If you have a ssh server, that's the best option for logging into a
machine over the network, to issue commands to it.

> doesn't seem to solve the problem of "what is blocking my request from
> one machine to another?"

Things that stand in the way of other things:

Firewall - generally configured with iptables, but there are some front
ends that take over, and sometimes you disable one firewall service to
allow another one to do its job.  Other firewall names, if I remember
them correctly - shorewall, firestarter.  Some of them are just
configurators, giving you an interface to tweak iptables rules.  Others
take over, as an independent firewall.  You also have to remember to
check whether you should be blocking/allowing TCP and/or UDP traffic to
those ports.

/etc/hosts.allow and /etc.hosts.deny - an older method of allowing and
denying some things.  Read those files.  If they don't list any servers
or addresses, in them, those control files will be ignored.

SELinux.  You could look through the selinux config tool for any mention
of "mail" or "send"ing to see if there's anything in there that may
block mail.

Sendmail configuration, itself, has lots of options about what it can
accept and send to.

And you will probably have little luck sending mail to another machine
if it doesn't have a real domain name (a domain that the recipient can
resolve its name).  e.g. If I try to send mail to the outside world from
root@localhost, most outside servers will reject it.  Your own SMTP
servers may be configured in the same way.

                    -----------------------

Long long ago, when dinosaurs roamed the earth (well, not quite), I set
up mail in my LAN, using the following method.  And it's probably the
easiest way to start out.  Once you get that working, you can try for
setting up multiple SMTP servers on your LAN.

I set one machine up as a SMTP server.  I used a normal mail client
program on the same machine, to test it (sending mail to itself).

I learnt how to configure the SMTP server to accept mail within my LAN
(e.g. listening for connections to 192.168.1.2 rather than just
listening to 127.0.0.1).  And used a mail client program on another
computer, to send mail to users on the mail server machine.

I learnt how to configure the SMTP server to be able to send mail out to
the world, using the smarthost option (my SMTP server is a relay to my
ISP's SMTP server).  And tested that using a mail client on my LAN to
send to my email address at my ISP.

NB:  Sending mail to the world, directly, probably isn't going to work.
You need a real domain name resolvable to your IP, your IP should be
static.  And having an IP within the pool of customer IP addresses of a
network, means that most external services will ignore you.

I haven't tried being my own SMTP server, accepting mail from the world
for my local users, because I don't want to have to do all the anti-spam
handling that would entail.

Later I did get inter-machine mail working on the LAN, but it was too
much of a hassle, for a variety of reasons:  Having to customise
sendmail on each machine to let it accept and send mail.  Having to
reconfigure mail clients on each machine, yet again.  Having to deal
with multiple MX records on my DNS server (as it stands, I have one MX
record, which means any mail to be sent to any subdomain within my LAN
is told that the mail server address is mail.example.com (a single
machine).  So, mail for fred.example.com or martha.example.com doesn't
go to a server on those machines, just to one central server.

Once you start playing with servers, on a small LAN, it really is useful
to set up one machine as a central server for a variety of things.

   It's my DNS server, resolving answers for local machine names, and
the names of anything on the internet.  It also censors some addresses,
so that certain domains just don't work for anything within my LAN (such
as doubleclick.com adverts and tracking).

   It's my DHCP server, doling out addresses to machines on my LAN, and
putting their names and IPs into my DNS server.  (No more fiddling about
with hosts files, anywhere, ever again.)

   It's my mail servers.  I send mail through it.  It holds local mail.
Remote mail is dragged into it, and local mail clients can access all
their mail on the local IMAP server.  I can hop onto any machine in the
LAN, and check all of my mail.  I don't have to always use one client on
one machine.

   It's my web server, file server, network time protocol server.  And,
as such, it becomes a general test machine for any other machine.

I wouldn't spread servers out onto separate machines, on a small LAN,
because it becomes more of a maintenance job to look after them.  On a
large LAN, I might.  Because it can become easier to switch out a whole
machine, to fix up a wonky webserver, without disrupting everything else
at the same time.

With a central mail/file/whatever server, most of the clients are basic
machines, and much easier to do system upgrades (no mail, files, or
other data needs backing up from them, you can just wipe and upgrade).

-- 
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.



-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux