[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [exim4] mixed up about terminology



On 10/12/2014 10:18 AM, lee wrote:
> Jerry Stuckle <jstuckle@attglobal.net> writes:
> 
>> On 10/8/2014 8:42 PM, lee wrote:
>>> Jerry Stuckle <jstuckle@attglobal.net> writes:
>>>
>>>> On 10/6/2014 7:30 PM, lee wrote:
>>>>> Jerry Stuckle <jstuckle@attglobal.net> writes:
>>>>>
>>>>>> For instance, MUAs typically connect on port 587 (at least that is the
>>>>>> recommendation), while MTAs always use port 25. Additionally, MUAs
>>>>>> should always be validated with signon/password, to prevent the server
>>>>>> from becoming an open relay.
>>>>>
>>>>> 1:  You would have to require auth on port 25 just in case a MUA
>>>>>     connects on that port.  Since you could reasonably do this
>>>>>     exclusively for connections from authorised clients (i. e. clients
>>>>>     on your LAN), it doesn't seem very useful (unless you need to be
>>>>>     afraid of misbehaving clients on your own LAN).
>>>>>
>>>>
>>>> No, you don't.  There is nothing in the RFC's which require port 25 to
>>>> be open to MUA's.  OTOH, there is an RFC 2476 reserves port 587
>>>> specifically for such submission.
>>>
>>> How do you distinguish a MUA from an MTA at that point?
>>>
>>
>> MUAs are supposed to use Port 587, as indicated by RFC 2476.  MTAs use
>> Port 25.
> 
> That doesn't answer my question.  How do you distinguish a MUA from an
> MTA at that point?
> 
>>> Are you sure the authentication your MTA requires is secure?
>>>
>>
>> Yes.
> 
> How can you be sure?  Did you check the source code of all software
> that's involved and then compile it?
> 
>> If you don't have authentication on your MTA, anyone who gets into your
>> network can send whatever emails they want.
> 
> They could do that anyway because when they break in, they could either
> change the configuration of the MTA or run an MTA on their computer
> which is connected to my network to send emails.  I haven't bothered to
> prevent the latter, and the first is possible unless I pull the plug.
>

Only if they have root access to your server.  Breaking into your
network does not require that.

> Do you have a good suggestion how to prevent the sending of emails from
> my network other than through my MTA?  That would include blocking all
> webmail clients and all relay hosts someone could have set up somewhere
> to use arbitrary ports to send out messages through.
> 

Require authorization on your MTA.  That way only authorized user can do so.


> If you're that paranoid, you have no choice but to disconnect from the
> internet.  But perhaps you can convince me otherwise by showing us how
> you prevent the sending of emails from a LAN other than through the
> designated MTA without removing all internet connectivity for everything
> else but the MTA.
> 

I am not paranoid.  But I do know security.  And your network is NOT secure.

>>>> And large companies and governments spend millions of dollars a year to
>>>> secure their systems.  They are constantly monitoring their logs and
>>>> running tests, looking for holes.  They use commercial gear which is
>>>> quite expensive.  They have sysadmins with years of experience in both
>>>> administration and security.  Yet they still manage to get hacked.
>>>
>>> Their networks tend to be a bit more endangered than a small LAN at
>>> home is.
>>>
>>
>> A false assumption.  Anyone connected to the internet can be endangered.
> 
> You didn't understand what I was saying.  That everyone is endangered
> doesn't mean that everyone is endangered to the same extent.  My LAN
> doesn't involve 500 or so offices with hundreds or thousands of users
> who could attempt to somehow send email via my LAN.
> 

I understood completely.  And my statement stands.  It doesn't matter
whether you have two systems on your network or 200,000.  If your
network is not secure, your email is not secure the way you have it set up.

>>>> Are you saying you and your equipment are better than them?
>>>
>>> You only need to be good enough.
>>>
>>
>> Which requires a certain level of security - including authentication to
>> ANY resource on the network.
> 
> That a certain level of security is required doesn't mean that you must
> require authentication to all resources.  Do you have switches or
> something that require(s) authentication when someone plugs in a network
> cable?  Do you have your computers locked in in a big vault to prevent
> intruders physical access to them?
>

Any resource which does not require authentication is, by definition,
insecure.  Do you run your systems with no password for root?

>>>> I know a lot about security (it comes with living in the paranoid
>>>> security capital of the world).  I've spent a lot of time securing my
>>>> network with multiple levels of security.  But I'm not naive enough to
>>>> believe my network can't be hacked.
>>>
>>> That's one of the problems with security.  It takes a lot of time to
>>> learn, a lot of time to implement and then a lot of time to use because
>>> you need to enter another password all the time.  And you don't even
>>> believe it's worthwhile yourself.
>>>
>>
>> Yup, and it only takes a little time for a hacker or spammer to break an
>> insecure system.
>>
>> But how do you say I don't believer it's worthwhile?  Where have I EVER
>> said anything of the sort?  I KNOW security - and what it entails.
> 
> You assume it's possible to break in, no matter what you do.  When it's
> possible anyway, then why go to all the lengths?
> 

That is correct.  That's what security is all about.  You protect
everything; that way if there is a break-in the damage is controlled.

>>>>> 3:  How do you deal with messages not generated by MUAs when you have
>>>>>     blocked your MTA against the LAN through requiring auth?
>>>>>
>>>>>
>>>>
>>>> I don't require authorization on port 25.  But I also don't allow it.
>>>> All authorized users must go through port 587.  Unauthorized users can
>>>> only go through port 25, and have restricted rights.
>>>
>>> So your systems aren't functioning because messages not generated by
>>> MUAs cannot be delivered?
>>>
>>>
>>
>> All of my messages generated by MUAs are delivered just fine.
> 
> I was asking about the messages not generated by MUAs.
> 
> 

I don't have any messages not generated by MUAs.  MTAs do not generate
messages.

Jerry


Reply to: