On Wed, 2004-11-03 at 11:54, Alexander Dalloz wrote: > Am Mi, den 03.11.2004 schrieb Ow Mun Heng um 4:31: > > > > > How can one Explicitly bind the milters then? > > > > > > Paul posted it recently, so did I. It is set via the sendmail.mc in the > > > sendmail.cf. See Paul's posting: > > > [SNIP] > > > http://marc.theaimsgroup.com/?l=fedora-list&m=109845682807103&w=2 > > > http://marc.theaimsgroup.com/?l=fedora-list&m=109884722321154&w=2 [SNIP] Thanks for the info. > > > > > > > * How much do you trust authenticating users? When malware gets > > > > > > sent (unknown to the orginator) does it send through the users > > > > > > MUA (eg: if users are using Outlook(R) > > > > > > > > > > In which way is that specific for using the MSA? If you have a worm on a > > > > > Windows[tm] machine being able to use the auth data saved within the > > > > > mail program, then it does not matter whether you use the MTA or the > > > > > MSA. As server administrator you can hardly handle such cases. Only if > > > > > you have a close eye on the logs and you observer suspicious sendings. > > > > > > > > That statement was closely related to my 1st point eg: If the MSA does > > > > not run any milters. Then it _would_ matter wouldn't it? > > > > > > I don't understand why that depends on any milter? Sendmail handles the > > > authentication by using SASL. How should any daemon (not Sendmail > > > specific question) distinguish valid and "stolen" auth data? Do you have > > > any sophistic milter in mind? > > > > You misunderstood me. I'm not talking about auth and the like. (meaning, > > since outlook (r) caches the auth etc.. it's meaningless actually once > > comprimised) I was merely stating that MSAs, (like mine) does not have > > milters binded. (at least I think it doesn't, whcih I need to check) > > I must confess that you lost me somewhere. I do not understand your > point. If the auth data of a client/user is misused on the client side - > how should the server detect this? I'm not saying it can be detected. My point is simply, assuming these : 1. MSA on port 587, MTA on port 25. 2. Milters running on port 25 3. No Milters running on port 587. 4. Incoming External mails goes to port 25 5. Internal Outgoing mails goes to port 587 (SMTP AUTH/TLS etc) that outgoing mails are _not_ scanned by any milters (to save cpu cycles). ( I still need to check on that - I just did, since my submit.mc points my msp to localhost, it's getting miltered. Drats) Incoming mails are via port 25 and gets through the milters. > > > You need to run the MTA on port 25 if you want to receive mail by > > > unknown users / other servers. There may be scenarios where users with a > > > "private" mail server on a dial-in line don't need to receive mail by > > > other servers. Ok, those could close the MTA. > > > > Unless they, like me, run fetchmail to feed > > the mails to the MTA for the milters to work > > As said, the milters are available too if mail is processed via the MSA. > fetchmail can deliver the fetched mail differently than just to a > running MTA on port 25. Are you talking about the -S option for fetchmail? (Keyword: smtp[host]) Specify a hunt list of hosts to forward mail to (one or more hostnames, comma-separated). Hosts are tried in list order; the first one that is up becomes the forwarding target for the current run. Normally, `localhost' is added to the end of the list as an invisible default. Each hostname may have a port number following the host name. The port number is separated from the host name by a slash; the default port is 25 Thanks for un-confusing me..
