Hi guys, Is it possible to use multiple milters with sendmail? and if so, what determines the order they are applied?
ie.
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`@(#)ohpp')dnl OSTYPE(linux)dnl FEATURE(nocanonify)dnl MASQUERADE_AS(ohpp.com)dnl FEATURE(allmasquerade)dnl dnl Milter dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER') define(`MAIL_HUB', `mail.domain.com')dnl define(`SMART_HOST', `mail.domain.com')dnl define(`confFORWARD_PATH', `')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl dnl SpamAssassin Milter INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') dnl ClamAV Milter INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clamav/clamd.sock, F=, T=S:4m;R:4m')dnl define(`confINPUT_MAIL_FILTERS', `clmilter')dnl dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl EXPOSED_USER(`root')dnl MAILER(smtp)dnl
many thanks, Yang
Oh, found it. #### README.libmilter
Which filters are invoked and their sequencing is handled by the InputMailFilters option. Note: if InputMailFilters is not defined no filters will be used.
O InputMailFilters=filter1, filter2, filter3
This is is set automatically according to the order of the INPUT_MAIL_FILTER commands in your .mc file. Alternatively, you can reset its value by setting confINPUT_MAIL_FILTERS in your .mc file. This options causes the three filters to be called in the same order they were specified. It allows for possible future filtering on output (although this is not intended for this release).
Also note that a filter can be defined without adding it to the input filter list by using MAIL_FILTER() instead of INPUT_MAIL_FILTER() in your .mc file.
Yang
On Fri, 22 Oct 2004 10:40:25 -0400, Yang Xiao yxiao2004@gmail.com wrote:
Hi guys, Is it possible to use multiple milters with sendmail? and if so, what determines the order they are applied?
ie.
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`@(#)ohpp')dnl OSTYPE(linux)dnl FEATURE(nocanonify)dnl MASQUERADE_AS(ohpp.com)dnl FEATURE(allmasquerade)dnl dnl Milter dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER') define(`MAIL_HUB', `mail.domain.com')dnl define(`SMART_HOST', `mail.domain.com')dnl define(`confFORWARD_PATH', `')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl dnl SpamAssassin Milter INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') dnl ClamAV Milter INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clamav/clamd.sock, F=, T=S:4m;R:4m')dnl define(`confINPUT_MAIL_FILTERS', `clmilter')dnl dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl EXPOSED_USER(`root')dnl MAILER(smtp)dnl
many thanks, Yang
Yang Xiao wrote:
Oh, found it. #### README.libmilter
Which filters are invoked and their sequencing is handled by the InputMailFilters option. Note: if InputMailFilters is not defined no filters will be used.
O InputMailFilters=filter1, filter2, filter3
Ah yes, the separator is a comma in confINPUT_MAIL_FILTERS in 8.12.x but it's a semicolon in the InputMailFilters= part of DAEMON_PORT_OPTIONS in 8.13.x. Watch out for this when you upgrade to FC3... if you use a comma you'll just be running the first of your milters and the rest will be ignored, something I fell over a few months ago.
Paul.
Yang Xiao wrote:
Hi guys, Is it possible to use multiple milters with sendmail?
Yes.
and if so, what determines the order they are applied?
The order in which you specify them in your confINPUT_MAIL_FILTERS entry in the .mc file.
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`@(#)ohpp')dnl OSTYPE(linux)dnl FEATURE(nocanonify)dnl MASQUERADE_AS(ohpp.com)dnl FEATURE(allmasquerade)dnl dnl Milter dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER') define(`MAIL_HUB', `mail.domain.com')dnl define(`SMART_HOST', `mail.domain.com')dnl define(`confFORWARD_PATH', `')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl dnl SpamAssassin Milter INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') dnl ClamAV Milter INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clamav/clamd.sock, F=,T=S:4m;R:4m')dnl define(`confINPUT_MAIL_FILTERS', `clmilter')dnl
define(`confINPUT_MAIL_FILTERS', `spamassassin;clmilter')dnl
dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl EXPOSED_USER(`root')dnl MAILER(smtp)dnl
At least that's how I *think* you do it in sendmail 8.12.x. I'm using 8.13.x and only run milters on the MTA daemon, not on the MSA:
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.
On Fri, 2004-10-22 at 22:52, Paul Howarth wrote:
At least that's how I *think* you do it in sendmail 8.12.x. I'm using 8.13.x and only run milters on the MTA daemon, not on the MSA:
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
Ah.. You were answering the other post from me regarding the MSA/MTA/MSP.
You mentioned you run the milters on the MTA instead of the MSA. Right now, I have both the MTA and MSA running, and the milters (spam/clamav) are running on the MTA.
Evo is configured to hand off the emails to the local sendmail program, but from what it looks like, I think it's still going to the MTA, hence going through the milters. This should not be necessary right? How do I change it?
Appreciate any comments.
Am Do, den 28.10.2004 schrieb Ow Mun Heng um 4:02:
Evo is configured to hand off the emails to the local sendmail program, but from what it looks like, I think it's still going to the MTA, hence going through the milters. This should not be necessary right? How do I change it?
Simply don't use "Sendmail" as send method in Evolution's setup but "SMTP" and then configure to use port 587 for using the MSP.
Alexander
On Thu, 2004-10-28 at 03:02, Ow Mun Heng wrote:
On Fri, 2004-10-22 at 22:52, Paul Howarth wrote:
At least that's how I *think* you do it in sendmail 8.12.x. I'm using 8.13.x and only run milters on the MTA daemon, not on the MSA:
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
Ah.. You were answering the other post from me regarding the MSA/MTA/MSP.
You mentioned you run the milters on the MTA instead of the MSA. Right now, I have both the MTA and MSA running, and the milters (spam/clamav) are running on the MTA.
Evo is configured to hand off the emails to the local sendmail program, but from what it looks like, I think it's still going to the MTA, hence going through the milters. This should not be necessary right? How do I change it?
There's more than one way to do this. Alexander's approach is probably the simplest, having multiple MTAs listening on different interfaces (one on localhost, one on your external IP) and only scanning mail that comes through the "external" MTA. However, this isn't a suitable approach for you because in a different email you said that you use fetchmail to collect mail and then push it through your local MTA (on localhost presumably) to get the virus/spam scanning done. So you need the milters to run on the localhost MTA. A slight variation would be to run another, non-scanning MTA on a different localhost address (e.g. 127.1.1.1) and have your submit.cf use that MTA.
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:
1. Create an AUTH user ID for the client:
saslpasswd2 -a Sendmail -c -u <server-hostname> <msp-username> --> when prompted, enter the password
2. Create an authinfo database for the client to use:
cat > /etc/mail/msp-authinfo AuthInfo:127.0.0.1 "U:<msp-username>" "P:secret" "M:DIGEST-MD5" ^D makemap hash msp-authinfo < msp-authinfo chgrp smmsp msp-authinfo*
3. Add msp-authinfo.db to the end of the "all" target in /etc/mail/Makefile
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')
these need to go before the FEATURE(`msp'... line.
5. Add to sendmail.mc:
LOCAL_RULESETS SLocal_trust_auth R$* $: $&{auth_authen} Rsmmsp $# OK
6. Update .cf files:
make
7. Restart sendmail
service sendmail restart
Paul.
On Thu, 2004-10-28 at 15:43, Paul Howarth wrote:
On Thu, 2004-10-28 at 03:02, Ow Mun Heng wrote:
[snip] ... [/snip]
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:
Why do you need to have AUTH?? Your Relay provides AUTH is it? (or I gather it's your own MTA somewhere) Lookin at the headers, it's goalkeeper.
GoalKeeper is TLS Enabled, and thus encrypted, but after it reaches mx1.redhat.com, it becomes plaintext. (correct?)
[snip]
- Create an AUTH user ID for the client:
saslpasswd2 -a Sendmail -c -u <server-hostname> <msp-username> --> when prompted, enter the password
.... [/snip] Thanks for the detail write up. Needs some digestion.
dnl Use the MSA with AUTH define(`RELAY_MAILER_ARGS', `TCP $h 587')
What's $h? Hostname? port 587? That's the definition of the MSA right?
- Add to sendmail.mc:
LOCAL_RULESETS SLocal_trust_auth R$* $: $&{auth_authen} Rsmmsp $# OK
What about this in the sendmail-cf docs? Other things don't work well with the MSP and require tweaking or workarounds. For example, to allow for client authentication it is not just sufficient to provide a client certificate and the corresponding key, but it is also necessary to make the key group (smmsp) readable and tell sendmail not to complain about that, i.e.,
define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile')
Additionally the MTA must trust this authentication data so the AUTH= part will be relayed on to the next hop
Now.. The question is, does it retain it's TLS/encrypted state after leaving the MSA or MTA? on to the next mail hop?
Ow Mun Heng wrote:
On Thu, 2004-10-28 at 15:43, Paul Howarth wrote:
On Thu, 2004-10-28 at 03:02, Ow Mun Heng 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:
Why do you need to have AUTH?? Your Relay provides AUTH is it? (or I gather it's your own MTA somewhere) Lookin at the headers, it's goalkeeper.
I defined my MSA as follows: DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
The "a" mailer flag enforces authentication before the MSA will accept mail. This stops spammers or viruses from using the submission port for delivery of local mail, bypassing milters and other spam checks etc. A result of that is that any client (including the MSP) that wants to send mail through the MSA must authenticate first. Both the MTA and MSA support AUTH.
GoalKeeper is TLS Enabled, and thus encrypted, but after it reaches mx1.redhat.com, it becomes plaintext. (correct?)
sendmail will use TLS if it is available (and configured). Delivery will resort to plain text at any point that doesn't support TLS.
dnl Use the MSA with AUTH define(`RELAY_MAILER_ARGS', `TCP $h 587')
What's $h? Hostname? port 587? That's the definition of the MSA right?
This is telling the MSP to relay mail out using the MSA instead of the MTA, i.e. connect to port 587 of the destination host $h (always the same host for the MSP, usually localhost) instead of port 25.
- Add to sendmail.mc:
LOCAL_RULESETS SLocal_trust_auth R$* $: $&{auth_authen} Rsmmsp $# OK
What about this in the sendmail-cf docs? Other things don't work well with the MSP and require tweaking or workarounds. For example, to allow for client authentication it is not just sufficient to provide a client certificate and the corresponding key, but it is also necessary to make the key group (smmsp) readable and tell sendmail not to complain about that, i.e.,
define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile')
Additionally the MTA must trust this authentication data so the AUTH= part will be relayed on to the next hop
The Local_trust_auth ruleset above is the bit that causes MTA to trust the authentication data from the MSP.
You only need define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') if you're doing TLS (i.e. with certificates). Regular SMTP AUTH doesn't need certificates.
Now.. The question is, does it retain it's TLS/encrypted state after leaving the MSA or MTA? on to the next mail hop?
Only if the next hop supports it. Some do, most don't.
Paul.
On Thu, 2004-10-28 at 15:43, Paul Howarth wrote:
On Thu, 2004-10-28 at 03:02, Ow Mun Heng wrote:
Evo is configured to hand off the emails to the local sendmail program, but from what it looks like, I think it's still going to the MTA, hence going through the milters. This should not be necessary right? How do I change it?
There's more than one way to do this. Alexander's approach is probably the simplest, having multiple MTAs listening on different interfaces (one on localhost, one on your external IP) and only scanning mail that comes through the "external" MTA. However, this isn't a suitable approach for you because in a different email you said that you use fetchmail to collect mail and then push it through your local MTA (on localhost presumably) to get the virus/spam scanning done. So you need the milters to run on the localhost MTA. A slight variation would be to run another, non-scanning MTA on a different localhost address (e.g. 127.1.1.1) and have your submit.cf use that MTA.
I think I comprehend what you are saying now. I just looked at my submit.mc (again) and noticed that my
FEATURE(`msp',`[127.0.0.1]')dnl
Which basically still means it's being sent through the localhost MTA. (DUH!)
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:
- 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?
Thanks
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:
- 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.
Paul.
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:
- 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)
How can I tell?
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:
- 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?
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 restarting sendmail, all locally-submitted mail should then get stuck in clientmqueue because the MSP cannot connect to the MSA.
What's the output of:
fgrep -i milter /etc/mail/sendmail.mc
on your system?
Paul.
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:
- 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)
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.
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)
mail from evo is stuck in outbox. (configured to use the MSA which is closed)
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
Ow Mun Heng wrote:
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:
- 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.
On Wed, 2004-11-03 at 19:03, Paul Howarth wrote:
Ow Mun Heng wrote:
[BIG SNIP]
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:
DUH!!! I'm going home now. i'll look at it closer when I get home and report back tomorrow. Really appreciate your patience.
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.
- 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.
Got it Finally.
I just tried your
DAEMON_OPTIONS(`Port=smtp,Name=MTA, InputMailFilters=headercheck-milter;spfmilter')dnl
and changing the INPUT_MAIL_FILTER to INPUT_FILTER, it does not work. Likely, it's not compiled with _FFR_MILTER_PERDAEMON
How can one check? What's the sendmail -d0.? line?
And I don't see the MILTTER_PERDAEMON anywhere within the readme files in sendmail-docs.
Where Can I find it? aarrgghhh,, wish I have I-net access now!
Thank
Ow Mun Heng wrote:
I just tried your
DAEMON_OPTIONS(`Port=smtp,Name=MTA, InputMailFilters=headercheck-milter;spfmilter')dnl
and changing the INPUT_MAIL_FILTER to INPUT_FILTER, it does not work. Likely, it's not compiled with _FFR_MILTER_PERDAEMON
If you didn't build it yourself (i.e. it's one that came with Fedora) then it won't have it.
Where Can I find it? aarrgghhh,, wish I have I-net access now!
Probably the easiest option for you is to grab the sendmail-8.13.1 SRPM from fedora/development/SRPMS on your favourite mirror and build it on your machine:
rpmbuild --rebuild sendmail-8.13.1-2.src.rpm
That'll give you 8.13.1 built for FC2.
Paul.
On Wed, 2004-11-03 at 20:12, Paul Howarth wrote:
Ow Mun Heng wrote:
I just tried your
DAEMON_OPTIONS(`Port=smtp,Name=MTA, InputMailFilters=headercheck-milter;spfmilter')dnl
and changing the INPUT_MAIL_FILTER to INPUT_FILTER, it does not work. Likely, it's not compiled with _FFR_MILTER_PERDAEMON
If you didn't build it yourself (i.e. it's one that came with Fedora) then it won't have it.
Where Can I find it? aarrgghhh,, wish I have I-net access now!
Probably the easiest option for you is to grab the sendmail-8.13.1 SRPM from fedora/development/SRPMS on your favourite mirror and build it on your machine:
rpmbuild --rebuild sendmail-8.13.1-2.src.rpm
That'll give you 8.13.1 built for FC2.
Okay.. It's complete. I've tested it and it works great. Thanks for the info.
I consider this issue closed. (For Now.... )
Am Mi, den 03.11.2004 schrieb Ow Mun Heng um 12:54:
I just tried your
DAEMON_OPTIONS(`Port=smtp,Name=MTA, InputMailFilters=headercheck-milter;spfmilter')dnl
and changing the INPUT_MAIL_FILTER to INPUT_FILTER, it does not work. Likely, it's not compiled with _FFR_MILTER_PERDAEMON
Please be careful. It is "MAIL_FILTER" like Paul said and not "INPUT_FILTER"!
How can one check? What's the sendmail -d0.? line?
/usr/lib/sendmail -bt -d0.13 < /dev/null | grep FFR
Alexander
On Thu, 2004-11-04 at 01:39, Alexander Dalloz wrote:
Am Mi, den 03.11.2004 schrieb Ow Mun Heng um 12:54:
I just tried your
DAEMON_OPTIONS(`Port=smtp,Name=MTA, InputMailFilters=headercheck-milter;spfmilter')dnl
and changing the INPUT_MAIL_FILTER to INPUT_FILTER, it does not work. Likely, it's not compiled with _FFR_MILTER_PERDAEMON
Please be careful. It is "MAIL_FILTER" like Paul said and not "INPUT_FILTER"!
Whoops.. My Bad.
How can one check? What's the sendmail -d0.? line?
/usr/lib/sendmail -bt -d0.13 < /dev/null | grep FFR
it's not compiled with it. I guess It's compile time then
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:
- 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)
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 to use the MSA port.
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)
mail from evo is stuck in outbox. (configured to use the MSA which is closed)
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
Am Fr, den 22.10.2004 schrieb Yang Xiao um 16:40:
Is it possible to use multiple milters with sendmail? and if so, what determines the order they are applied?
Yes, sure it is possible and no problem. The order they are called by Sendmail is determined by either the simple order in the sendmail.cf file (originated by the sendmail.mc file you created the .cf from) or by an explicit definition of confINPUT_MAIL_FILTERS, like you use below.
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') dnl ClamAV Milter INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clamav/clamd.sock, F=, T=S:4m;R:4m')dnl
From that "spamassassin" milter would come first and then the "clmilter" milter.
define(`confINPUT_MAIL_FILTERS', `clmilter')dnl
Due to this definition _only_ the "clmilter" milter will be used and the "spamassassin" milter ommited.
From the Sendmail README:
"In general, INPUT_MAIL_FILTER() should be used unless you need to define more filters than you want to use for `confINPUT_MAIL_FILTERS'.
Note that setting `confINPUT_MAIL_FILTERS' after any INPUT_MAIL_FILTER() commands will clear the list created by the prior INPUT_MAIL_FILTER() commands."
Yang
Alexander
Am Fr, den 22.10.2004 schrieb Yang Xiao um 16:40:
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`@(#)ohpp')dnl OSTYPE(linux)dnl FEATURE(nocanonify)dnl MASQUERADE_AS(ohpp.com)dnl FEATURE(allmasquerade)dnl dnl Milter dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER') define(`MAIL_HUB', `mail.domain.com')dnl define(`SMART_HOST', `mail.domain.com')dnl define(`confFORWARD_PATH', `')dnl define(`STATUS_FILE', `/var/log/mail/statistics')dnl define(`UUCP_MAILER_MAX', `2000000')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl dnl SpamAssassin Milter INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass.sock, F=,T=C:15m;S:4m;R:4m;E:10m') dnl ClamAV Milter INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clamav/clamd.sock, F=, T=S:4m;R:4m')dnl define(`confINPUT_MAIL_FILTERS', `clmilter')dnl dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(use_ct_file)dnl EXPOSED_USER(`root')dnl MAILER(smtp)dnl
Yang
Annotation to this sendmail.mc: - please respect that the entries shall follow an order: define lines in front of all FEATURE lines - APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER') this is a compile setting for site.config.m4 and has not to be in any sendmail.mc (though you already commented it) - you have no MAILER(local) line; has to be in front of the MAILER(smtp) line
Alexander