MSA & MTA & Milters Was [Re: Firewall and NAT]

[Alexander Dalloz]

Am Mi, den 03.11.2004 schrieb Ow Mun Heng um 3:13:

> > > The other concern with this and the method of using MSAs is
> > >       * It does not have any milters/filters in place. what's stopping
> > >         spam/malware etc from coming in through that path?
> > 
> > If you don't explicitly bind the milters to the MTA only, they are used
> > with the MSA too.
> > 
> Interesting. My submit.{cf | mc} does not contain a lot of things except
> for the default MSP to use.
> 
> 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:

http://marc.theaimsgroup.com/?l=fedora-list&m=109845682807103&w=2

My posting:

http://marc.theaimsgroup.com/?l=fedora-list&m=109884722321154&w=2

> > >       * 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?

Of course, if you want to restrict your users which have authed in
specific ways, you may use some add-ins which can be a milter
application.

> > > I believe that sendmail is right to instruct that the MSA only be used
> > > on internal systems. (and if there's a choice, only for the sending
> > > system and not to accept from other connections on the LAN). I guess it
> > > also depends, how much you trust systems within your LAN or otherwise
> > 
> > If you don't open the default MSA - means without authentication
> > enforcement -, then I wouldn't see the problem you see.
> 
> Okay, let's put it this way. For users such as myself, who uses *nix and
> is sure that there are _no_ malware that affects 99% of the non
> *nix/*bsd systems, then usage of the MSA w/o any milters is useful.

Please explain me in which way you see here a difference to using the
MTA. You refer to the things Leonard Isham quoted here in this thread?

> If however, the original poster only wanted to open up a MTA/MSA for his
> user that has port 25 blocked by the ISP, I see no reason in just
> running another MTA in another port for that user. (but frankly, all
> that trouble for the 1 user? hehe) Better yet, port-forward the default
> port 25 to another server running a MTA on say port 2525. That way,
> there's only 1 listening MTA.

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. In any other case where
you want to receive mail by others unknown you need the open MTA for
local delivery or controlled relaying (i.e. an internal final mail
server).

Alexander


-- 
Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.8-1.521smp 
Serendipity 03:24:00 up 14 days, 1:03, load average: 0.37, 0.39, 0.51 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20041103/e2430616/attachment-0002.bin