On Sun, 19 May 2002, Jim Osborn wrote:
[...] To my surprise, I was informed by a relay testing server that I was running an open relay, and, sure enough, my sendmail DOES relay. I had a line "127 RELAY" in /etc/mail/access, so I removed that line, leaving access empty, but upon retesting, I'm still relaying. It's not a huge exposure, dynamic IP, brief connections, but it's not right, and I intend to fix it.
This line does no harm. Leave it in the access db. You could start sendmail with an additional -O DaemonPortOptions=Addr=127.0.0.1 to make it listen only on your loopback interface. This is default on SuSE since 8.0 (i think). Another approach would be to block incoming connections for port 25 with some filter rules.
If someone knows offhand, maybe they can reduce my research: Has SuSE done something to enable relaying by default? Do I need some stuff in my access database to restrict relaying, even if I really don't want to relay anything from outside to outside? If so, what's the access line for "deny all except to/from localhost"?
The docs and faqs I'm reading all go into elaborate detail on the subject of allowing controlled relaying, whereas I'm more interested in NO relaying.
The problem are the dialup specific features/hacks. See below.
I tried turning off the sendmail daemon, per the above reasoning. But then fetchmail began failing, and per the fetchmail FAQ, I needed to have an SMTP listener for fetchmail to pass the mail to. When I
Recent versions of fetchmail use the procmail or sendmail binary if there is no listener on port 25. Don't know if your fetchmail does the same. See man fetchmail and look for keyword `mda'.
FEATURE(`expensive')dnl FEATURE(`nocanonify')dnl HACK(`nodns')dnl FEATURE(`dialup', `not.a.registered.domain')dnl
These features/hacks turn off several rulesets needed for spam detection and relaying. They indirectly call delay_all_checks, nocanonify, .... Have a look at the corresponding files in /usr/share/sendmail and the README file. (btw. you probably only need FEATURE(`expensive')) Hope that helps. -- Best regards / Mit freundlichen Gruessen, Andreas Amann < andreas.amann@epost.de >