Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
We have a sendmail mailserver inside our LAN. It basically works, but I have the feeling that it is not configured quite correctly. However, I do not have a clue what causes the following faults:
- when the smtp server is specified as mail.foo.bar in the mail clients, then some mails sent by these clients are rejected by the recepients with 'Sender domain must exist' error. When the smtp server is specified as serverneme.foo.bar, no mails are rejected. However I must configure many clients to use mail.foo.bar; these are notebooks that may connect to the mailserver also from outside our LAN.
- some user complains that they cannot send mail to their own mailboxes from outside our LAN (they say they can send mail to any other addresses)
- I could not send a mail with pine from our mailserver either I specified mail.foo.bar or servername.foo.bar as the mailserver.
What can be the reason for the above faults?
And my final question: I want to enable the notebooks to send mail via our mailserver even when they are outside our LAN. However, these notebooks only have private IP addresses inside our LAN, and no public IP addresses when they are outside. Since they do not have static IP addresses, I do not know how to allow relaying for these machines only, and not for all machines on the internet.
What is the common solution for this?
divert(-1)
dnl This is the macro config file used to generate sendmail.cf
dnl file. If you modify this file you will have to regenerate
dnl sendmail.cf by running this macro config through the m4
dnl preprocessor:
dnl
dnl m4 /home/phil/Documents/sendmail.mc > /etc/sendmail.cf <--Change to your path
dnl
dnl You will need to have the sendmail-cf RPM installed for this
dnl to work, if you use an rpm build of sendmail
dnl
dnl include(`../m4/cf.m4')
dnl
dnl If you compile sendmail from a tarball, use the include above.
dnl In this setup, you should create the file as cf/cf/config.mc
dnl (in the sendmail source tree: eg. /usr/src/sendmail-8.11.6/cf/cf
dnl Now give the command "sh Build config.cf". Now copy the file
dnl config.cf as /etc/mail/sendmail.cf (please backup first!)
dnl
dnl If you are using the RPM build of sendmail, use the
dnl include statement given below instead
dnl
include(`/usr/share/sendmail-cf/m4/cf.m4')
define(`confDEF_USER_ID',``8:12'')
OSTYPE(`linux')
undefine(`UUCP_RELAY')
undefine(`BITNET_RELAY')
define(`confCF_VERSION',`dialup-1.3')
define(`SMART_HOST', `smtp.yourisp.com') <--Change this
define(`confAUTO_REBUILD')
define(`confTO_CONNECT', `1m')
define(`confTO_IDENT',0)
define(`confTRY_NULL_MX_LIST',true)
define(`confDONT_PROBE_INTERFACES',true)
define(`confCON_EXPENSIVE',true)
define(`confDELIVERY_MODE', `queued')
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')
define(`ALIAS_FILE',`/etc/mail/aliases')
MASQUERADE_AS(`yourisp.com') <--Change this
FEATURE(`masquerade_envelope')
FEATURE(`smrsh',`/usr/sbin/smrsh')
FEATURE(`mailertable',`hash -o /etc/mail/mailertable')
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(`use_ct_file')
FEATURE(local_procmail)
MAILER(smtp)
MAILER(procmail)
FEATURE(`access_db')
FEATURE(`blacklist_recipients')
FEATURE(`accept_unresolvable_domains')
FEATURE(`accept_unqualified_senders')
dnl FEATURE(`relay_based_on_MX')
You can make it work, but only if you give your mailserver public IP or forward all mail ports to it (smtp and pop3). It should also solve problems of users who can't send mail from outside and the notebook users (the public IP will work in both cases).
How is your DNS MX entry configured? Where does it point?
We have one public IP for mail.foo.bar. It is the IP address of our firewall, and port 25 of our internal mailserver is forwarded to port 25 on the firewall, so the mailserver listens there. Pop3 is OK.
However, relaying is only allowed for a remote premise of us. I can configure it, since that site has static IP address. The notebooks have no static IP addresses, so I do not know how to allow relaying for them.
Here are the MX records:
castor IN A 192.168.226.2
IN MX 10 mail
foo.bar. IN MX 100 castor
mail IN CNAME castor.foo.bar.
;mail IN MX 13 castor.foo.bar.
There is another way. Google for "POP before SMTP" and DRAC. What happens is when a user "pops" his mail from your unix box the incoming IP address is added to a list similar to /etc/mail/access. This (incoming laptop IP address) will be good for 30 minutes (configurable) and then they'll need to pop again. The downside is that they have to pop to your unix box. If they don't have an account on it you will need to create one for them for just this purpose. For large networks DRAC is the better option.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.