If you are using dynamic IP numbers (and many service providers will only give you a dynamic IP number unless you pay significantly more for your connection), then you have to recognise the limitations this imposes.
First of all, outbound service requests will work just fine. That is, you can send email using sendmail (provided you have correctly set up sendmail), ftp files from remote sites, finger users on other machines, browse the web etc.
In particular, you can answer email that you have brought down to your machine whilst you are off line. Mail will simply sit in your mail queue until you dial back into your ISP.
However, your machine is NOT connected to the Internet 24 hours a day, nor does it have the same IP number every time it is connected. So it is impossible for you to receive email directed to your machine, and very difficult to set up a web or ftp server that your friends can access! As far as the Internet is concerned your machine does not exist as a unique, permanently contactable machine as it does not have a unique IP number (remember - other machines will be using the IP number when they are allocated it on dial in).
If you set up a WWW (or any other server), it is totally unknown by any user on the Internet UNLESS they know that your machine is connected AND its actual (current) IP number. There are a number of ways they can get this info, ranging from you ringing them, sending them email to tell them or cunning use of ".plan" files on a shell account at your service provider (assuming that your provider allows shell and finger access).
Now, for most users, this is not a problem - all that most people want is to send and receive email (using your account on your service provider) and make outbound connections to WWW, ftp and other servers on the Internet. If you MUST have inbound connections to your server, you should really get a static IP number. Alternatively you can explore the methods hinted at above...
Even for dynamic IP numbers, you can certainly configure sendmail on your
machine to send out any email that you compose locally. Configuration of
sendmail can be obscure and difficult - so this document does not
attempt to tell you how to do this. However, you should probably
configure sendmail so that your Internet service provider is designated
as your "smart relay" host (the sendmail.cf DS option). (For more
sendmail configuration info, see the sendmail documents - and look at the
m4 configurations that come with sendmail. There is almost certain to be
one there that will meet your needs).
There are also excellent books on Sendmail (notably the 'bible' from O'Reilly and Associates), but these are almost certainly overkill for most users!
Once you have sendmail configured, you will probably want to have sendmail dispatch any messages that have been sitting in the outbound mail queue as soon as the PPP connection comes up. To do this, add the command
sendmail -q &
to your /etc/ppp/ip-up script (see below).
Inbound email is a problem for dynamic IP numbers. The way to handle this is to:-
You can automate this process at dial up time by putting the necessary
commands in the /etc/ppp/ip-up script (see below).
Whilst you can quite happily use the domain name servers located at your ISP, you can also set up a local caching only (secondary) name server that is brought up by the ip-up script. The advantage of running a local (caching only) name server is that it will save you time (and bandwidth) if you frequently contact the same sites during a long on-line session.
DNS configuration for a caching only nameserver (that uses a "forwarders' line in the named.boot file pointing at your ISPs DNS) is relatively simple. The O'Reilly book (DNS and Bind) explains all you want to know about this.
There is also a DNS-HOWTO available.
If you are running a small LAN that can access the Internet through you Linux PC (using IP Masquerade for example), it is probably a good idea to run a local name server (with a forwarders directive) whilst the link is up as this will minimise the bandwidth and delays associated with name resolution.
One point of Nettiquette: ask permission from your ISP before you start using a secondary, caching only name server in your ISP's domain. Properly configured, your DNS will not cause any problems to your ISP at all, but if you get things wrong, it can cause problems.