Re: Current status?

In article <6ikm81Frd7puU1@xxxxxxxxxxxxxxxxxx>, billg999@xxxxxxxxxxx (Bill Gunshannon) writes:
In article <g9r0lf$g15$1@xxxxxxxxxxxxxxxxx>,
david20@xxxxxxxxxxxxxxxx writes:
In article <7h%vk.609$393.335@trnddc05>, John Santos <john@xxxxxxx> writes:
Bill Gunshannon wrote:
In article <g9pl82$lh7$4@xxxxxxxxx>,
helbig@xxxxxxxxxxxxxxxxxxxxxxxx (Phillip Helbig---remove CLOTHES to reply) writes:

In article <t_Wvk.2076$U5.1028@xxxxxxxxxxxxxxx>,
=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= <jan-erik.soderholm@xxxxxxxxx>
writes:



Yup. I think that many of the problems arise because MUAs use the same
protocol (SMTP) and port (25) to send mail to MTAs as MTAs use to relay
mail to each other.

Modern MTAs can be configured to allow mail clients to submit mail to them on
the mail submission port (port 587) rather than port 25. See RFC 2476
http://www.faqs.org/rfcs/rfc2476.html

What does this buy you? You would still need to know who your MTA is
andc it would still need to be willing to accept email from you. It is
all the silly little notification apps that wree brought up here as
justification for allowing anybody to use port 25. They have no builtin
method of authenticating so the port number used changes nothing. I
certainly would not accept email on my MTA from someone on port 587 that
I would not also accept on port 25. The purpose of port 587 sand RFC
2476 is noto to control SPAM it is to make sure outgoing email meets
the proper formating requoirements of the other RFC's.

As RFC 2476 says in section 1

"
Separating messages into submissions and transfers allows developers
and network administrators to more easily:

* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail

* Implement authenticated submission, including off-site submission
by authorized users such as travelers
"


In order for SMTP mail to function your MTA has to accept connections on port
25 from pretty much anywhere. You cannot setup port 25 to only accept
unauthenticated mail from certain internal systems and to require all other
mail to be authenticated because that would stop you receiving mail from all
over the world. However with the submission port you can set it up so that it
will only accept unauthenticated connections from certain internal addresses
and will REQUIRE all other connections to be authenticated using
SASL/SMTP-AUTH. Hence you can split mail into two different trust levels -
mail coming over port 25 and the more trusted mail from your own
users/internal systems coming over the submission port.
This also ties in with anti-spam measures such as SPF where you can no longer
have your homeworkers using their work domain when sending mail out through
their local ISP but instead have to have them sending via your organisation's
MTAs (since those are the only MTAs registered to be able to use that domain).
To prevent anti-relaying you will need your remote users to authenticate using
SASL/SMTP-AUTH when sending through your organisation's MTAs and this is best
accomplished using the submission port (not least because the ISP may well be
blocking direct connections to external systems over port 25 but should not be
blocking the submission port - which should be more secure since anyone setting
it up should require remote connections to it to be authenticated).




On the other hand MTAs talk to MUAs (when delivering
mail) using either of 2 different protocols (that I know of), POP3 on
port 110 and IMAP on port 143. (I don't think anything does POP2 on
port 109 any more.)

Logically there are three parties involved not two.
MTA, MUA and Message store.

Not sure what you make as differnt with "Message store". Unless you
are separating the guy MTA from the machine that runs POP or IMAP.
I don't see that as necessarily being a separate Email function although
it is possible and may even have some utility on a big enough system.


A POP Server, IMAP Server and SMTP server are three totally different services.
The point is that POP and IMAP are not used by the MTA to deliver mail to
anybody. POP and IMAP are as explained below strictly used to access the
message store.

ie the statement

"
On the other hand MTAs talk to MUAs (when delivering
mail) using either of 2 different protocols (that I know of), POP3 on
port 110 and IMAP on port 143. (I don't think anything does POP2 on
port 109 any more.)
"

is nonsense.



The MTA delivers mail to another MTA or to a message store.
The MUA originates mail and sends it to a MTA.
Mail clients generally incorporate the above MUA functionality together with
the ability to display and manipulate mail in the message store.

POP and IMAP are protocols used to access and manipulate the message store.
They are NOT used to deliver mail to the message store.

Agreed, but the "Message Store" is not necessarily even a part of the
Email system and I don't believe it has ever been considered by IETF.
I have users who use NFS to read their email. Does that make NFS an
Email Protocol, too? And, of course, Wessage Store is also irrelevant
to the problem of how to get the email system to be more immune to SPAM.


Note.

The SMTP servers which come with the TCPIP stacks (TCPWARE, MULTINET or TCPIP
SERVICES/UCX) are NOT fully fledged modern MTAs. For that you would need either
PMDF or MX.
(
PMDF is a commercial product but is available free for hobbyist use.
MX is now an open-source free product see
http://www.madgoat.com/
However I'm not aware of anyone currently continuing development of MX.
)


Maybe so, but if people played by the rules, basic SMTP is more than adequate
to the task. If ISP's blocked port 25 for all machines in their domain other
than their MTA I would need to filter incoming ports on my end. And RBL's
would rapidly become redundant.

Unfortunately we haven't even managed to get to the position where every ISP
and company in the USA and Europe block port 25 for all bar their MTAs let
alone the rest of the world. Since that and other measures aren't likely to be
adopted soon we are left with trying to shore up our own front-door defenses.

Sadly, we are forced to spend a lot of time effort and technology trying
to, once again, solve a social problem. A social solution would work a
lot better.

True but unfortunately it is one thing to get a small group of like minded
people to agree to and follow a social solution. It is another matter to get
everybody in the whole world to agree.


David Webb
Security team leader
CCSS
Middlesex University


bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@xxxxxxxxxxxxxxx | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
.

Relevant Pages

  • Re: Current status?
    ... You would still need to know who your MTA is ... justification for allowing anybody to use port 25. ... In order for SMTP mail to function your MTA has to accept connections on port ... Not sure what you make as differnt with "Message store". ...
    (comp.os.vms)
  • Re: Current status?
    ... You would still need to know who your MTA is ... justification for allowing anybody to use port 25. ... Not sure what you make as differnt with "Message store". ... Email Protocol, too? ...
    (comp.os.vms)
  • Re: Current status?
    ... You would still need to know who your MTA is ... justification for allowing anybody to use port 25. ... Not sure what you make as differnt with "Message store". ... Email Protocol, too? ...
    (comp.os.vms)
  • Re: Current status?
    ... justification for allowing anybody to use port 25. ... MTA, MUA and Message store. ... the ability to display and manipulate mail in the message store. ... Email Protocol, too? ...
    (comp.os.vms)
  • Re: email servers
    ... some port to receive email from the outside world (this is port 25?, ... The MTA can also listen on the SMTP port for sending mail from the local host to others. ... Depending on whether you consider IMAP or POP3 daemons as part of the MTA or not, since they would listen on the appropriate ports, the MTA would or would not. ... will have to be configured so that LAN traffic stays on the LAN ...
    (Debian-User)
Quantcast