[RBL] Current status? - VMS

This is a discussion on [RBL] Current status? - VMS ; In article , FrankS writes: > I think I understand your position, but I wouldn't agree that making > those changes will eliminate, nor necessarily reduce the amount of > spam in the world. All that would be accomplished is ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 76 of 76

Thread: [RBL] Current status?

  1. Re: Current status?

    In article
    ,
    FrankS writes:

    > I think I understand your position, but I wouldn't agree that making
    > those changes will eliminate, nor necessarily reduce the amount of
    > spam in the world. All that would be accomplished is that spammers
    > would become a bit more inventive (or better financed) to accomplish
    > their goals.


    Spam exists because it is cheap and easy. If the spammers have to
    become better financed, or become more inventive, then the motivation is
    reduced. Whether it is reduced enough to make a significant dent in the
    problem is the question.


  2. Re: Current status?

    In article <48c5bdb4$0$12396$c3e8da3@news.astraweb.com>, JF Mezei
    writes:

    > However, TCPIP Services' lack of authentication prevents you from using
    > your smtp server while away (from mobile phone or wi-fi enabled device).


    I can send an email from my mobile phone through the mobile-phone
    provider.

    > You require authentication to allow "foreigners" to get full service on
    > your SMTP service without allowing spammers to use your smtp service to
    > relay billions and billions of messages about magic pills.


    Yes, but that is only necessary if I need to relay for folks outside my
    LAN, which I don't.


  3. Re: Current status?

    In article <6ikm81Frd7puU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >In article ,
    > david20@alpha2.mdx.ac.uk writes:
    >> In article <7h%vk.609$393.335@trnddc05>, John Santos writes:
    >>>Bill Gunshannon wrote:
    >>>> In article ,
    >>>> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >>>>
    >>>>>In article ,
    >>>>>=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
    >>>>>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@cs.scranton.edu | and a sheep voting on what's for dinner.
    >University of Scranton |
    >Scranton, Pennsylvania | #include


  4. Re: Current status?

    Bill Gunshannon wrote:

    > ISP's can and should be doing this now. It doesn't need another port.
    > All their internal MUA's can use port 25 as it is no differnt than their
    > using port 587. No one but there MTA should be sending outside their
    > email domain on port 25 or accepting incoming email connection on port
    > 25. Adding a "submission" port doesn't change that.


    Hotmail, Yahoo, Gmail and another "mass market" email provider would
    disagree. They need a way for users to submit emails sign by their
    addresses to their servers.

    From a spam protection point of view, those services don't want people
    to send emails signed by their domain via some ISP's SMTP server because
    that ISP has no way to authenticate those users.

    587 bypasses the port 25 blocks, and allows anyone to connect to the
    yahoo/hotmail/gmail SMTP servers to authenticate and send their emails.
    This way, it allows people to refuse emails signedby some yahoo.com
    email address unless it comes from a yahoo.com email server. (aka: SPF
    checking).

  5. Re: Current status?

    Phillip Helbig---remove CLOTHES to reply wrote:
    > In article
    > ,
    > FrankS writes:
    >
    >> I think I understand your position, but I wouldn't agree that making
    >> those changes will eliminate, nor necessarily reduce the amount of
    >> spam in the world. All that would be accomplished is that spammers
    >> would become a bit more inventive (or better financed) to accomplish
    >> their goals.

    >
    > Spam exists because it is cheap and easy. If the spammers have to
    > become better financed, or become more inventive, then the motivation is
    > reduced. Whether it is reduced enough to make a significant dent in the
    > problem is the question.


    At one of my former broadband ISPs, they had an internal newsgroup where
    any of their customers could post on.

    One of the things that came out is that several times when a virus
    outbreak happened so that viruses got relayed through the MTA, users
    immediately started complaining about at least two well know ISPs were
    now refusing all e-mail from that ISP until until a representative from
    that ISP contacted them to tell them the problem was fixed. It took
    typically 24 hours to get the block removed.

    After the second time, the ISP hired a security person to start fixing
    the problems.

    Their experience can not be unique.

    So if e-mail delivery is important to a network, then that network needs
    to make sure that it does not have spam problems.

    And having a virus infected computer on a commercial network is not just
    a nuisance, it is a serious liability to the company, because it means
    that unknown criminals have probably have access to confidential
    information.

    And I thought that the Healthcare industry was one of those that had
    high confidentiality requirements for their systems and networks.

    So detecting and neutralizing viruses is an essential part of a
    business, unless it can change all of its systems to ones that are not
    easily infected.

    So when you find an indicator that can be used to detect compromized
    systems with a high degree of accuracy, I would expect they would want
    to use it.

    And none of this should be hard for any network that uses commercial
    routers and managed switches.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  6. Re: Current status?

    In article , david20@alpha2.mdx.ac.uk
    says...
    > In article <6ikm81Frd7puU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    > >In article ,
    > > david20@alpha2.mdx.ac.uk writes:
    > >> In article <7h%vk.609$393.335@trnddc05>, John Santos writes:
    > >>>Bill Gunshannon wrote:
    > >>>> In article ,
    > >>>> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    > >>>>
    > >>>>>In article ,
    > >>>>>=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
    > >>>>>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.
    >
    >


    I beg to differ. The point is that the last step of the mail transfer
    (reception by the mail client) is different from the previous steps.
    I was trying to be brief (never works), so left out all the details
    of how the mail gets from the SMTP server to the IMAP and POP servers.


    The mail client, using either POP or IMAP, *pulls* the mail and
    *doesn't* use SMTP for this. I skipped over the complexity of
    describing mail stores because it was beside the point.

    Whether the destination MTA is also a POP/IMAP server is an
    implementation detail. Sendmail uses various delivery agents
    to write to the mail store, and a separate POP or IMAP server
    reads and delivers to the client at the client's request. MX
    and the SMTP servers included in the various VMS stacks use
    callable VMS MAIL to write the mail to the regular VMS mail files.
    (At least, TCPware and UCX work this way, I assume Multinet works
    like TCPware.) I think PMDF uses its own mail store, but I don't
    know, having never used it. I don't know if the PMDF POP/IMAP
    servers are included in the SMTP server, or if they are separate
    processes, or if PMDF just uses the underlying stack's POP and
    IMAP servers. I don't know what MS Exchange does and don't
    really want to. :-) How the recipient MTA interacts with the
    recipient MUA is an unimportant implementation detail, I was
    just trying to point out that it's different and uses a different
    protocol.

    > >>
    > >> 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.
    > >


    Sure it is. The mail has to go *somewhere* eventually. It can't just
    keep spinning around the Internet forever :-) Bur usually, it goes to
    the same place that the host operating system's native local mail
    program stores mail, so isn't a network issue, and there is no reason
    for the IETF to be involved. You can then use the host o/s's native
    mail program to read the internet mail directly from the store or
    use a completely different mechanism (i.e. POP or IMAP) to pull it
    down to a client. (By "use NFS", I guess you mean they use the native
    local mail program to read it from an NFS-mounted disk.)


    > >>
    > >> 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@cs.scranton.edu | and a sheep voting on what's for dinner.
    > >University of Scranton |
    > >Scranton, Pennsylvania | #include

    >


    --
    John

  7. Re: Current status?

    In article , John Santos writes:

    >Whether the destination MTA is also a POP/IMAP server is an
    >implementation detail. Sendmail uses various delivery agents
    >to write to the mail store, and a separate POP or IMAP server
    >reads and delivers to the client at the client's request. MX
    >and the SMTP servers included in the various VMS stacks use
    >callable VMS MAIL to write the mail to the regular VMS mail files.
    >(At least, TCPware and UCX work this way, I assume Multinet works
    >like TCPware.) I think PMDF uses its own mail store, but I don't
    >know, having never used it. I don't know if the PMDF POP/IMAP
    >servers are included in the SMTP server, or if they are separate
    >processes, or if PMDF just uses the underlying stack's POP and
    >IMAP servers. I don't know what MS Exchange does and don't
    >really want to. :-) How the recipient MTA interacts with the
    >recipient MUA is an unimportant implementation detail, I was
    >just trying to point out that it's different and uses a different
    >protocol.




    PMDF has its own multithreaded IMAP and POP servers which fit into it's
    dispatcher architecture. The PMDF messagestore is n extra-cost option;
    IMAP and POP can work off the VMS mail store. PMDF can deliver either
    to the VMS mail store or to its own messagestore. You pretty much need
    to use the PMDF SMTP server to get stuff into the PMDF world, but if
    you don't configure in IMAP and POP servers you can use the ones provided
    with your IP package.

    Not your point, but I thought I'd make this clear.

    -- Alan

  8. Re: Current status?

    In article ,
    david20@alpha2.mdx.ac.uk writes:
    > In article <6ikm81Frd7puU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >>In article ,
    >> david20@alpha2.mdx.ac.uk writes:
    >>> In article <7h%vk.609$393.335@trnddc05>, John Santos writes:
    >>>>Bill Gunshannon wrote:
    >>>>> In article ,
    >>>>> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >>>>>
    >>>>>>In article ,
    >>>>>>=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
    >>>>>>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.


    True.

    > 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.


    I don't have a problem with my internal users being on port 25 and
    unauthenticated. They are "authenticated" by being inside my firewall.
    It's the outsiders that are the problem. None of my machines are or
    ever has been "zombied".

    > 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).


    Or, use a VPN and leave them on the inside, where they belong.

    None of this "submission port" stuff addresses the real problem in any
    way. My MTA must have port 25 open to the world and I am still left
    trying to use RBL's to identify those who should not be connecting to
    me. This is reactive and relies on an unreliable method and requires
    trust of people I have no particular reason to trust. Not a very good
    security model.

    >
    >>>
    >>>
    >>>> 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.


    Well, I wouldn't have gone that far but I would assume the person saying
    it has a very limited understanding of how email really works. That would
    put him/her in a group made up of 99% of email users. :-)

    >
    >
    >>>
    >>> 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.


    As I have said numerous times before you will never find a technological
    solution because this is a social problem. The solution exists. The only
    argument against it to date has been the administrative overhead looks
    immense. But, when you look at the effort spent trying to "shore up" the
    existing system the one time effort of my proposal plaes in comparison.

    >
    >>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.


    You don't need to get everyone. Just the people who run the email system(s)
    and want to see it work and require a lot less of thier time than it does now.

    bill

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

  9. Re: Current status?

    In article <48c5d531$0$4543$c3e8da3@news.astraweb.com>,
    JF Mezei writes:
    > Bill Gunshannon wrote:
    >
    >> ISP's can and should be doing this now. It doesn't need another port.
    >> All their internal MUA's can use port 25 as it is no differnt than their
    >> using port 587. No one but there MTA should be sending outside their
    >> email domain on port 25 or accepting incoming email connection on port
    >> 25. Adding a "submission" port doesn't change that.

    >
    > Hotmail, Yahoo, Gmail and another "mass market" email provider would
    > disagree. They need a way for users to submit emails sign by their
    > addresses to their servers.


    I didn't say there was no use for the service on port 587. I said
    it was irrelevant to wether or not port 25 should be blocked for all
    machines in your email domain other than your real, legitimate MTA.
    If they choose to accept connection from anyone on the outside, that
    is their right, but again, it is irrelevant to the question of wether
    or not one should allow one's users to send directly to other MTA's.


    >
    > From a spam protection point of view, those services don't want people
    > to send emails signed by their domain via some ISP's SMTP server because
    > that ISP has no way to authenticate those users.


    When you allow your users to talk directly to other MTA's you really
    have little control over what domain they "sign" their emails with.
    Another reason why you need to force all email thru your MTA.

    >
    > 587 bypasses the port 25 blocks, and allows anyone to connect to the
    > yahoo/hotmail/gmail SMTP servers to authenticate and send their emails.


    But the problem isn't that someone uses 587 it is that contrary to what
    you seem to think, port 25 is not being blocked in most places, particulary
    ISP's.

    > This way, it allows people to refuse emails signedby some yahoo.com
    > email address unless it comes from a yahoo.com email server. (aka: SPF
    > checking).


    Once again, you are placing the burden and the cost on the receiving
    end. It would be better to prevent it rather than try to remediate it.
    And it can be done!!

    bill

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

  10. Re: Current status?

    In article , John Santos
    writes:

    Nothing new, just trimming the hundreds of lines of quoted text.

    > Even if an ISP blocks external port 25 (which their customers would
    > probably complain about if they are running their own inbound mail
    > servers, or just on principal :-), do any implement internal firewalls
    > that block one customer from trying to access another? For Comcast
    > in particular, if I understand it correctly, each neighborhood is a
    > LAN on a virtual ethernet running on their cable, so there is not
    > even a router between you and the guy down the street. The only
    > place they could put a firewall is on the cable converter box that
    > converts the cable signal to ethernet in your house (the box commonly
    > called a "cable modem", though I don't think it is really a modem.)
    > They could *also* firewall port 25 at their boundaries with other
    > ISPs and backbone providers, but that in itself would be
    > insufficient. (They might want to do it anyway to reduce their
    > internal traffic.)
    >
    > I'm on Verizon FIOS at home and I know the FIOS converter box
    > is a router and does NAT and some level of filtering, so inbound
    > port 25 traffic wouldn't make it to my LAN (or single computer
    > if that was all I had) unless I actively reconfigure it to pass
    > port 25 to a designated host (the default is "block"), but I
    > don't know if the same applies to Comcast cable modems. (FIOS
    > is point-to-point to the central office, like DSL, so local
    > "LAN" traffic isn't a separate issue like it would be with
    > Comcast.) In other words, blocking at the upstream router or
    > at my home would be equally effective with FIOS or DSL, but
    > for Comcast, only blocking at the home would catch everything.
    >
    > As far as making SPAM go away, most of mine seems to come from
    > China, South America, and other places, and gets sent through
    > the legitimate ISP inbound mail server. It would have to
    > be blocked at all those remote ISP's which are completely out
    > of control. And blocking port 25 inbound through the ISP's
    > perimeter to anything other than its MX-designated mail servers
    > would still do nothing about compromised hosts or deliberate
    > SPAMing by other customers of the same ISP going through its
    > outbound and then inbound mail servers. It would make the
    > offending hosts identifiable, but wouldn't stop them. The
    > ISP would have to notice and then take action (which many of
    > them do, but they have to send several hundred emails before
    > anything gets triggered.) The SPAMers don't care. If they
    > get several hundred sent from each zombie before they get
    > stopped, they're happy, and the rest of us suffer.
    >
    > As far as liberals coddling SPAMers, I'm a liberal and I
    > say "hang'em now. We can have the trial later!"
    >
    >
    > --
    > John Santos
    > Evans Griffiths & Hart, Inc.
    > 781-861-0670 ext 539


  11. Re: Current status?

    In article <6iv84fFma4eU1@mid.individual.net>, billg999@cs.uofs.edu
    (Bill Gunshannon) writes:

    > If you are a residential customer:
    > 1. You probably don't have a clue what ahy of this means.
    > 2. You have no need to run your own mail server.
    > 3. Your AUP (at least for every ISP in the US who's AUP I am familiar
    > with) prohibits you from running an servers.


    My experience as a residential customer (in Germany): No ports are
    blocked, neither coming in nor going out. No prohibition against
    running servers. When I first set up things at home, I of course tried
    to send email directly from my cluster, which sometimes worked. Often,
    it didn't. The reason was that I had a volatile IP address which was
    blocked by the recipient (because it was in a block of volatile IP
    addresses). This was done because it stops a lot of spam, and I later
    started doing it myself. My solution: send email through an SMTP relay
    server run by the same person who handles my dynamic DNS
    ( http://www.dynaccess.de/ ). Since the maintainer takes care that no
    spam is sent through his server, no-one blocks it. (His terms and
    conditions also specify a hefty fee for anyone trying to send spam
    through it.) I do have to pay a bit more than I otherwise would for
    this service, but the cost is negligible compared to, say, the cost for
    the electrical power to run my cluster.

    If everyone did this, there would be a lot less spam. One way is for
    folks to block email from volatile IP addresses, forcing the senders to
    send it through a trusted, white-hat server. The other would be for
    ISPs to block it except through a trusted server. This assumes that the
    ISP runs a mail server himself.

    In my case, I wouldn't like this solution, but prefer to send through
    the server at my dynamic-DNS provider. Why? Because it is IP-based
    (he knows my IP because he handles my DNS). My ISP (1&1) requires
    either my official email address with them in the From: header (not
    something I want, since I might not stay with 1&1 forever) or SMTP
    authentication, which (at least my version of) HP TCPIP services for VMS
    cannot handle. In principle, of course, my ISP could do the same thing,
    since he knows my IP address as well (my router gets it via DHCP).


  12. Re: Current status?

    Bill Gunshannon wrote:


    > Blocking port 25 is just a bandaid, but the only one we have available
    > right now.


    Here is an example. Bell Canada,s residential ISP business (formerly
    known as Sympatico, not sure what its name is this week) didn't manage
    its email properly. (the word properly could be removed from the
    sentence). Spammers knew it, and the Bell IP block (sympatico doesn't
    have its own ASN, it uses that of the main Bell network) started to be
    used to send billions and billions of spams. Not suprisingly, the whole
    Bell IP block got onto RBLs.

    It is only once the press started to write articles about how Bell had
    been blacklisted and Bell customers (not just sympatico) couldn't send
    emails to many recipinets anymore that Bell management decided that some
    token action should be taken to make Bell apppear to manage its mail
    network.

    The easy fix is to block port 25. When you are a large scale ISP, it
    becomes harder to scan all your customers and spot unusual traffic and
    turn it off before it becomes a problem.

    Since then, Bell just outsourced its email to Microsoft and washed its
    hands off of it.

  13. Re: Current status?

    In article , Johnny Billquist
    writes:

    > And some people decide to block my mails. Well, that can be a problem
    > for me. It can be a problem for them. I still won't use the idiots
    > running the ISP for my mail. If you haven't realized they are clowns,
    > it's just because you haven't really looked at how they work.


    As long as your port 25 is not blocked, you could use someone else's
    SMTP server to send email through.


  14. Re: Current status?

    Phillip Helbig---remove CLOTHES to reply skrev:
    > In article , Johnny Billquist
    > writes:
    >
    >> And some people decide to block my mails. Well, that can be a problem
    >> for me. It can be a problem for them. I still won't use the idiots
    >> running the ISP for my mail. If you haven't realized they are clowns,
    >> it's just because you haven't really looked at how they work.

    >
    > As long as your port 25 is not blocked, you could use someone else's
    > SMTP server to send email through.


    As long as they relay mails, which they probably shouldn't. And otherwise we're
    talking about me going through some clowns servers again, which was exactly the
    thing I wasn't interested in.
    So if they let me, then they really prove that I shouldn't use them. :-)

    Johnny

    --
    Johnny Billquist || "I'm on a bus
    || on a psychedelic trip
    email: bqt@softjar.se || Reading murder books
    pdp is alive! || tryin' to stay hip" - B. Idol

  15. Re: Current status?

    In article , Johnny Billquist
    writes:

    > > As long as your port 25 is not blocked, you could use someone else's
    > > SMTP server to send email through.

    >
    > As long as they relay mails, which they probably shouldn't. And otherwise we're
    > talking about me going through some clowns servers again, which was exactly the
    > thing I wasn't interested in.
    > So if they let me, then they really prove that I shouldn't use them. :-)


    No, I mean some official white-hat server operator. :-)


  16. Re: Current status?

    Phillip Helbig---remove CLOTHES to reply skrev:
    > In article , Johnny Billquist
    > writes:
    >
    >>> As long as your port 25 is not blocked, you could use someone else's
    >>> SMTP server to send email through.

    >> As long as they relay mails, which they probably shouldn't. And otherwise we're
    >> talking about me going through some clowns servers again, which was exactly the
    >> thing I wasn't interested in.
    >> So if they let me, then they really prove that I shouldn't use them. :-)

    >
    > No, I mean some official white-hat server operator. :-)


    There are none.

    Johnny

    --
    Johnny Billquist || "I'm on a bus
    || on a psychedelic trip
    email: bqt@softjar.se || Reading murder books
    pdp is alive! || tryin' to stay hip" - B. Idol

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4