Sometimes, only one side of the firewall can launch telnet sessions into the other side; however, some means of communication is possible (typically, through e-mail). Piercing the firewall is still possible, by triggering with whatever messaging capability is available a telnet connection from the ``right'' side of the firewall to the other.
fwprc includes code to trigger such connections
from an OpenPGP-authentified email message;
all you need is add
fwprc as a
to messages using the protocol,
(instructions included in
Note however, that if you are to launch
with appropriate privileges,
you might need create your own suid wrapper to become root.
Instructions enclosed in
Also, authentified trigger does not remotely mean secure connection.
You should really use
ssh (perhaps over telnet)
for secure connections.
And then, beware of what happens between the triggering of a telnet
ssh taking over that connection.
Contribution in that direction welcome.
If you are firewalled, your mail may as well be in a central server
that doesn't do procmail filtering or allow telnet sessions.
No problem! You can run
in daemon mode (or within a cron job)
to poll your server and deliver mail to your linux system
which itself will have been configured to use
procmail at delivery.
Note that if you run
fetchmail as a background daemon,
it will lock away any other fetchmail that you'd like to run
only at other times, like when you open a
of course, if you can also run a fetchmail daemon as a fake user.
Too frequent a poll won't be nice to either the server or your host.
Too infrequent a poll means you'll have to wait before the message gets read
and the reverse connection gets established.
I use two-minute poll frequency.
Another way to poll for messages, when you don't have a mailbox, but do have outbound FTP access, is to use FTP tunnel.