On Wed, 2004-11-03 at 16:50, Paul Howarth wrote:On Wed, 2004-11-03 at 08:37, Ow Mun Heng wrote:On Wed, 2004-11-03 at 16:12, Paul Howarth wrote:On Wed, 2004-11-03 at 06:43, Ow Mun Heng wrote:On Thu, 2004-10-28 at 15:43, Paul Howarth wrote:However, to answer your original question, I have my MSP send mail out via my MSA, not my MTA, and this is how I do it:
4. Add to submit.mc:
dnl Use the MSA with AUTH define(`RELAY_MAILER_ARGS', `TCP $h 587') FEATURE(`authinfo', `hash /etc/mail/msp-authinfo')
Can I also find out what you have for the FEATURE(`msp',....) line?
Same as you: I'm connecting to the MSA on localhost:
FEATURE(`msp', `[127.0.0.1]')dnl
The 587 in RELAY_MAILER_ARGS directs it to port 587 rather than port 25.
I see.. So, in essense then you send outgoing mails through your localhost:587 (in evo configured as SMTP->localhost:587), you then bypass the milters? (DO you?)
I tried sending a test mail to my colleague and it still shows that it's going through port 25 as the Milter headers shows up (unless of course, as Alexander Dalloz said, it's binded to both)
You did rebuild submit.cf from your modified submit.mc and restart sendmail, didn't you?
Sorry.. I didn't put that into submit.mc (yet)
Right, so your MSP is not (yet) using the MSA.
My Submit.mc is very simple line FEATURE(`msp', `[127.0.0.1]')dnl
That's it except fo rthe Version/Ostype/etc)
So.. since evo is being configured to be sent out directly to port 587, the line
define(`RELAY_MAILER_ARGS', `TCP $h 587')
Shouldn't be needed right? It should only be needed if the MUA is not
pre-configured.
This is only needed if you want your MSP (for locally-submitted mail) to use the MSA.
How can I tell?
One way would be to temporarily turn off the MSA altogether by commenting out the DAEMON_OPTIONS line in sendmail.mc that defines it.
After doing that, I know the MSA port is closed as nmap shows it's closed and evo can't sent out emails. (Conn refused to port 587)
After restarting sendmail, all locally-submitted mail should then get stuck in clientmqueue because the MSP cannot connect to the MSA.
There's nothing stuck in clientmqueue. mail sent from the cli still gets delivered (MTA is open)
Indeed, because as you said earlier, the MSP is not (yet) configured to use the MSA.
mail from evo is stuck in outbox. (configured to use the MSA which is closed)
Right.
What's the output of:
fgrep -i milter /etc/mail/sendmail.mc
INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamd/clamav-milter.sock, F=, T=S:4m;R:4m')dnl INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl define(`confMILTER_MACROS_CONNECT',`b, j, _, {daemon_name}, {if_name}, {if_addr}')dnl
You are using INPUT_MAIL_FILTER, which applies to all daemons in that configuration file. So these milters will run on both MSA and MTA. To have different milters running on different daemons you need to either:
1. For sendmail 8.12.x not compiled with _FFR_MILTER_PERDAEMON
(this applies to stock Fedora 1/2 sendmails)
You need to have separate configuration files for MTA and MSA. The MTA configuration file should not define an MSA; the MSA configuration file *has* to define an MTA (you can't turn it off AFAIK), so you can define it to listen only on some unused local IP like 127.0.0.2. Unfortunately this means you end up with two daemons running.
2. For sendmail 8.13.x or sendmail 8.12.x compiled with _FFR_MILTER_PERDAEMON
Use MAIL_FILTER instead of INPUT_MAIL_FILTER to define your milters, and then use an InputMailFilters option for each daemon to specify which milters should run for which daemon.
MAIL_FILTER(`headercheck-milter', `S=unix:/var/run/headercheck-milter/headercheck-milter.sock, F=T, T=C:4m;S:4m;R:8m;E:16m')dnl
MAIL_FILTER(`spfmilter', `S=unix:/var/run/spfmilter/spfmilter.sock, F=T, T=C:4m;S:4m;R:8m;E:16m')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA, InputMailFilters=headercheck-milter;spfmilter')dnl
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
Paul.
