[RBL] Current status? - VMS

This is a discussion on [RBL] Current status? - VMS ; In article , david20@alpha2.mdx.ac.uk writes: > >All mail I send anywhere via TCPIP goes through the host specified as > >the alternate gateway. The highest-priority MX record is the WAN > >address of my LAN, which gets forwarded to the ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 76

Thread: [RBL] Current status?

  1. Re: Current status?

    In article , david20@alpha2.mdx.ac.uk
    writes:

    > >All mail I send anywhere via TCPIP goes through the host specified as
    > >the alternate gateway. The highest-priority MX record is the WAN
    > >address of my LAN, which gets forwarded to the cluster alias.


    On my ROUTER, of course, not on my LAN.

    > So your alternate gateway and MX record host are your designated MTAs which
    > should be allowed to communicate with the outside world over port 25.


    Right.

    > Any other systems on your internal network which wish to send mail out should
    > send out either directly or indirectly through the same alternate gateway.


    That's what they do. To the outside world, it looks like everything
    comes from the WAN address of the router.

    > Any mail for users on any other internal mail system should receive mail by it
    > first being passed to the MX system which then forwards it onto the internal
    > system.


    Internal mail is directly within the cluster, i.e. no TCPIP.

    > Hence the other internal systems do not require to open connections
    > directly to port 25 on arbitrary external systems or to have arbitrary
    > external systems connecting directly to port 25 on them. Your firewall can
    > therefore block those other internal systems from attempting such port 25
    > connections.


    The outside world can see only the WAN address, and that goes to the
    cluster alias on the LAN. All systems have the same SMTP configuration,
    in particular the same alternate gateway.

    > (You mention the WAN address of your LAN which suggests that you probably have
    > an internal network which is using dynamic NAT.


    Right, NAT and PAT.

    > Hence NAT is probably taking
    > care of stopping direct external connections to your other internal systems on
    > port 25 anyway.)


    Right.


  2. Re: [RBL] Current status?

    "John E. Malmberg" wrote:
    >
    > David J Dachtera wrote:
    > > "John E. Malmberg" wrote:
    > >>
    > >> A corporate firewall should be detecting and setting off security alarms
    > >> when a non-mail server attempts to make a direct SMTP connection through it.

    > >
    > > ...and there in lies the rub: too many vendor-managed proprietary
    > > (non-Windows) systems where the vendor is unwilling to "play by the
    > > house rules".

    >
    > If the system is supposed to send e-mail, then it can be let through the
    > firewall.


    Indeed.

    > If it is not supposed to send e-mail, and it attempts to, don't you
    > think someone should find out why?


    Naturally; however, who ever conducts the search needs to be aware that
    "legacy" systems will be encountered where either the vendor is
    unwilling to support enhancements or revisions or the vendor is defunct
    and the existing system must be tolerated as-is until it is
    de-implemented.

    > >> Another techique to use is a Samba Server configured to look like a
    > >> vulnerable PC to see what systems attempt to infect it.
    > >>
    > >> And Corporate/Educational network owners should consider being
    > >> suspicious of any outgoing e-mail with reply-to addresses for any of the
    > >> free/demo e-mailers:
    > >>
    > >> hotmail.com, live.com, live.ca, live.co.uk, live.*
    > >>
    > >> aol.com, games.com, aim.com, aol.*
    > >>
    > >> voila.fr, myway.com, gazeta.pl
    > >>
    > >> yahoo.com, rocketmail.com, ymail.com, yahoo.*
    > >>
    > >> gmail.com, googlemail.com

    > >
    > > Note: "should consider being suspicious of", but should not block
    > > arbitrarily.

    >
    > It depends what is more important to the business:
    >
    > Delivery of personal e-mails to non-business addresses through the
    > businesses e-mail servers/firewalls or the delivery of messages/pages
    > that are critical to the business.


    Both are absolutely vital. Neither can be excluded at the expense of the
    other.

    Welcome to the world of healthcare!

    > Or if it is important for the business to know if criminals have access
    > to private business and personal records.


    This is needed also; however, it MUST NOT UNDER ANY CIRCUMSTANCES
    interfere with normal operations.

    Again, welcome to the real world of healthcare, Neo!

    D.J.D.

  3. Re: [RBL] Current status?

    Bob Koehler wrote:
    >
    > In article , "John E. Malmberg" writes:
    > >
    > > If it is not supposed to send e-mail, and it attempts to, don't you
    > > think someone should find out why?

    >
    > We've had a lot of problems deploying COTS products that send
    > out notifications via email, from systems that the security folks
    > think shouldn't be "mail servers".


    In general, this handled by setting the appropriate outbound SMTP
    "relay" server, so the system(s) in question send mail to/through an
    "authorized sender" rather than each having outbound SMTP access
    directly through the firewall.

    > So "supposed to" is in the eye of the beholder.


    Quite.

    D.J.D.

  4. Re: Current status?

    Phillip Helbig---remove CLOTHES to reply wrote:
    > In article <4w_vk.522$1a2.373@trnddc04>, John Santos
    > writes:
    >
    >
    >>AKAIK, there is no standard, reliable way for a client to
    >>identify its own SMTP server for sending messages. The
    >>person setting up the client generally needs to be *told*
    >>this by the networking powers that be, and then set up the
    >>client appropriately.

    >
    >
    > $ TCPIP SET CONF SMTP/GATEWAY=ALTERNATE=
    >
    > In my case:
    >
    > Alternate gateway: SMTP-RELAY.DYNACCESS.DE
    >
    >
    >>This leads to 2 problems. 1) I've figured out how to
    >>coerce UCX (really HP TCP/IP Services for OpenVMS, but that
    >>is too damn long to type) into using "domain.com" instead
    >>of "host.domain.com",

    >
    >
    > Substitute domain?


    "substitute domain" doesn't work right in my situation. I need
    to check again what it did, but IIRC, it changed the host address
    in the "MAIL FROM:" RFC 821 header, but not in the "From:" RFC 822
    header, and I needed the opposite (or I only cared about the other
    one. But I could have this backwards...


    >
    >
    >>but I haven't figured out how to make
    >>it send from "known.user" instead of "username".

    >
    >
    > DEFINE TCPIP$SMTP_FROM ?
    >


    Again, it changes the 822 From: header, but not the 821
    "MAIL FROM:" header.

    I think I just got my MIME problem (see original post) sorted...
    Will post more about this when I get to it.

    TIA.

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  5. Re: Current status?

    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:
    >>>
    >>>
    >>>>>>Log watchers, webcam watchers,
    >>>>>>etc, anything which sends notification by email when something
    >>>>>>"interesting" happens, using its own built-in mail server;
    >>>>
    >>>>*Server* ?? I set up my cheap Zyxel DSL modem/router to send
    >>>>notifications to me, but it not a *server*. It uses whatever mail
    >>>>server it get's after doing a DSN-MX lookup on the receiver
    >>>>address, and that should be the official SMTP server of my
    >>>>ISP, as far as I understand.
    >>>>
    >>>>Why whould anything just needing to *send* a mail have a
    >>>>smtp *server* implementation ?
    >>>
    >>>You use "server" to mean "receiving end". A more general use, intended
    >>>here, is "handles traffic". Thus, incoming server and outgoing server.
    >>>You are sending your email TO the proper receiving server (via MX), but
    >>>it is still coming from your machine, not an "official email server".
    >>>Technically, there is no problem with your scheme, but in practice, such
    >>>machines on dial-up, volatile IP addresses are the main source of spam,
    >>>and are thus blocked by more and more people.
    >>>
    >>>Many STMP servers are neither senders nor receivers, but relays.

    >>
    >>
    >> Actually, the correct terminology is MUA and MTA.
    >> MUA = Mail User Agent.
    >> MUA's originate and terminate email.
    >>
    >> MTA = Mail Transport Agent
    >> MTA'a exchange email across the INTERNET.
    >>
    >> Nothing but MTA's should talk between email domains. No MUA shoud be
    >> allowed to acess anything but the local MTA. Thus the reason for blocking
    >> port 25 at your firewall for all internal hosts other than your designated
    >> MTA(s). User machines should never be considered MTA's. MTA's are the
    >> machines with the MX record in tghe DNS system. Violating this simple
    >> network engineering principle is why we have the SPAM probledm that we have.
    >> As for relaying, some MTA's relay. One should be very careful about who
    >> one relays for. You shold relay for your internal machines (all the MUA's)
    >> as that is the purpose of an MTA. You should not relay for external
    >> machines and if you do, that is a real quick way to find yourself on
    >> a blacklist.
    >>
    >> Email is really not that hard to manage.
    >>
    >> bill
    >>

    >
    > 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. 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.) I think if the mail origination and mail relay
    > functions and protocols had been kept distinct from the start, everything
    > would be much cleaner and under better control. For example, the way
    > you want to authenticate a mail originator is very different from the
    > way you want to authenticate a mail transport agent.


    As we once again blame the past for not anticipating the future. In the
    beginning, there really was no difference between the machines that were
    MTA's and MUA's. We read our email on the server from our VT100's. And,
    on top of all of this, it is still easily fixable but the people who need
    to fix it are either incompetent or just plain refuse to fix things.

    >
    > In their defense, SMTP is a "push" protocol (both for originating and
    > relaying mail), but POP3 and IMAP are "pull" protocols, so there's a
    > lot more commonality between an MUA sending to an MTA, and an MTA
    > forwarding mail to another MTA, than between them and mail delivery.
    > Also, these protocols originated before SPAM was an issue.


    There are a number of ways to fix things, one is relatively easy but
    requires the cooperation of people who, up to this point, have refused
    to play by the rules. The other, which I have tried suggesting but
    people just can't seem to grasp, frequires more work on the part of
    legitimate NTA admins but has the advantage of taking incompetent or
    just plain recalcitrant admins our of the picture completely. But I
    see us just sitting here and watching things get worse and worse until
    either a totally new systems comes around or people just give up on
    email for seruiuos use and relegate it to fluff, like the Web.

    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

  6. Re: Current status?

    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.

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

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

    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.


    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

  7. Re: [RBL] Current status?

    In article ,
    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > In article <6iakmbFpl207U2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >>
    >> Not really. Those particular devices should be sending their email to
    >> the real mailserver which should be the only one communicating with mail
    >> servers in the the outside world. If network/system managers, in particular
    >> ISP's, followed this rule 99% of SPAM cold be dealt with in ver short order.

    >
    > The problem isn't the path, it's the sending. They want to send via
    > SMTP, not POP, IMAP, or some other client protocol. As far as the
    > "security experts" are concerned, only servers send via SMTP.


    Not really. SMTP is the accepted way to send email from MUA's to MTA's.
    That's internal to an email domain. All external is done MTA to MTA and
    also uses SMTP. The problem is when one allows internal MUA's to connect
    to external MTA's directly on port 25. Simply blocking port 25 for all
    hosts, internal or external, except for connection to and from your real
    MTA solves this problem.

    >
    > I can't really fault a COTS vendor for sending email via SMTP.


    You can fault them for not providing enough of an agent to use the
    system properly. The correct way to do it is to not only set up
    a destination email address but also a realy host which would be
    your local MTA. Trust me, it's not really that hard to do.

    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

  8. Re: Current status?

    Bill Gunshannon wrote:
    > 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.
    >
    >>
    >>> 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.
    >
    >> 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.
    >
    > 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.


    Perhaps it would. But where would you get a "social solution"? How
    would you implement it? How would you deal with the anti-social creeps
    who "zombie" a PC or two or twenty and use them to pump spam into the
    net? Hint: you will NEVER get the liberals to agree to the death
    penalty! Hell, you can even spank a misbehaving child any longer!

  9. Re: Current status?

    In article ,
    "Richard B. Gilbert" writes:
    > Bill Gunshannon wrote:
    >> 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.
    >>
    >>>
    >>>> 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.
    >>
    >>> 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.
    >>
    >> 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.

    >
    > Perhaps it would. But where would you get a "social solution"? How
    > would you implement it? How would you deal with the anti-social creeps
    > who "zombie" a PC or two or twenty and use them to pump spam into the
    > net? Hint: you will NEVER get the liberals to agree to the death
    > penalty! Hell, you can even spank a misbehaving child any longer!


    Like I said, I have been over this a half-dozen tiems already. All that
    is needed already exists. It takes only administrative changes (which is
    why I said it would require more effort on the part of admins). If you
    are truly interested, email me and I will explain it to you. Or, if
    others actually express interest I will post it here again. But I
    expect most here are not in the least bit interested.

    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?

    Bill Gunshannon wrote:
    > In article ,
    > "Richard B. Gilbert" writes:
    >> Bill Gunshannon wrote:
    >>> 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.
    >>>
    >>>>> 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.
    >>>
    >>>> 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.
    >>>
    >>> 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.

    >> Perhaps it would. But where would you get a "social solution"? How
    >> would you implement it? How would you deal with the anti-social creeps
    >> who "zombie" a PC or two or twenty and use them to pump spam into the
    >> net? Hint: you will NEVER get the liberals to agree to the death
    >> penalty! Hell, you can even spank a misbehaving child any longer!

    >
    > Like I said, I have been over this a half-dozen tiems already. All that
    > is needed already exists. It takes only administrative changes (which is
    > why I said it would require more effort on the part of admins). If you
    > are truly interested, email me and I will explain it to you. Or, if
    > others actually express interest I will post it here again. But I
    > expect most here are not in the least bit interested.
    >
    > bill
    >


    My ISP has a spam filter effective enough that spam is not a problem for
    me! I get the occasional "401 scam" but that's about all. My curiousity
    is strictly idle. Please don't repost but if you have a link to an
    earlier post I'd be interested.

  11. Re: Current status?

    In article ,
    "Richard B. Gilbert" writes:
    > Bill Gunshannon wrote:
    >> In article ,
    >> "Richard B. Gilbert" writes:
    >>> Bill Gunshannon wrote:
    >>>> 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.
    >>>>
    >>>>>> 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.
    >>>>
    >>>>> 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.
    >>>>
    >>>> 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.
    >>> Perhaps it would. But where would you get a "social solution"? How
    >>> would you implement it? How would you deal with the anti-social creeps
    >>> who "zombie" a PC or two or twenty and use them to pump spam into the
    >>> net? Hint: you will NEVER get the liberals to agree to the death
    >>> penalty! Hell, you can even spank a misbehaving child any longer!

    >>
    >> Like I said, I have been over this a half-dozen tiems already. All that
    >> is needed already exists. It takes only administrative changes (which is
    >> why I said it would require more effort on the part of admins). If you
    >> are truly interested, email me and I will explain it to you. Or, if
    >> others actually express interest I will post it here again. But I
    >> expect most here are not in the least bit interested.
    >>
    >> bill
    >>

    >
    > My ISP has a spam filter effective enough that spam is not a problem for
    > me! I get the occasional "401 scam" but that's about all.


    And how many messages have you not receieved because of their SPAM filter?
    False Positives are at least as bad a problem as False Negatives. And for
    a business, they can be worse.

    And, before you sing the praises of Comcast...... I just looked at my
    logs and I have several hundred rejected connection from comcast addresses
    and that is just since midnight. They are part of the problem, not part
    of the solution. And not all of the rejections are Dynamic Addresses.
    Some of them "pen Relays" and "misconfigured servers". that means
    you may not only be missing incoming email but some of your outgoing
    email may not be getting through either. Ever send a request for
    information to a company and gotten pissed because they appear to just
    ignore you? Maybe the problem wasn't them but your ISP's mail system.

    > My curiousity
    > is strictly idle. Please don't repost but if you have a link to an
    > earlier post I'd be interested.


    No link, it was a subject that, like many others, comes and goes periodically.
    Let it suffice to say that a reactive technical solution has too strong a
    tendency to create more problems than it can solve. This is a social
    problem and the solution needs to be procative and social. The methods
    exist to do this. But creating social change is usually much harder than
    just hrowing technology at a problem. We see that every day. Sadly, the
    technological solutions almost never solve the problem and at best only
    delay things a little until the problem mutates around the new technology.

    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

  12. Re: Current status?

    The situation is simple really:

    Both 25 and 587 use SMTP.

    The difference:

    Port 25 is used to get calls from the outside for messages to be
    delivered to the inside. You can't require authentication for those. And
    for those calls, you do not accept to relay mail to another outside address.

    Port 587 is used to accept emails coming from the inside without
    authentication, and you allow relaying. (aka: sending to the outside
    world). And if a call comes in from the outside on port 587, you accept
    it if it is authenticated (username/password) and then allow relaying.



  13. Re: Current status?

    In article <48c56722$0$12415$c3e8da3@news.astraweb.com>,
    JF Mezei writes:
    > The situation is simple really:
    >
    > Both 25 and 587 use SMTP.
    >
    > The difference:
    >
    > Port 25 is used to get calls from the outside for messages to be
    > delivered to the inside. You can't require authentication for those. And
    > for those calls, you do not accept to relay mail to another outside address.
    >
    > Port 587 is used to accept emails coming from the inside without
    > authentication, and you allow relaying. (aka: sending to the outside
    > world).


    So how is this different from just using port 25?

    > And if a call comes in from the outside on port 587, you accept
    > it if it is authenticated (username/password) and then allow relaying.


    I can think of no reason I would ever relay for an outsider. Any reason
    I might have is handled by any of the MTA's I have used without any need
    to even know what port is being used. Sounds an awful lot like a solution
    looking fcor a problem to solve.

    And, it doesn't address the problem of firewalls with port 25 open.
    It just creates yet another potential attack vector.

    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

  14. Re: Current status?

    Bill Gunshannon wrote:
    > In article ,
    > "Richard B. Gilbert" writes:
    >> Bill Gunshannon wrote:
    >>> In article ,
    >>> "Richard B. Gilbert" writes:
    >>>> Bill Gunshannon wrote:
    >>>>> In article ,
    >>>>> "Richard B. Gilbert" writes:
    >>>>>> Bill Gunshannon wrote:
    >>>>>>> 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.


    >> My router blocks any and all connections that did not originate from my
    >> home network. If I check the router's logs, something I may do once or
    >> twice a year, there is somebody attempting a connection every fifteen to
    >> twenty seconds, twenty-four hours a day. Should I wish to receive
    >> incoming connections, I believe that I can configure it to allow
    >> specific originating addresses and ports but I can't think of any reason
    >> why I should want to. That box only cost me about $80 US and it has
    >> paid for itself several times over!

    >
    > Is this your home router? if it is, your ISP should never allow you
    > to even see them. That's what thier fifrewall is for. basicly, you
    > are paying for the infrastructure that provides the needed bandwidth
    > for all this garbage. (Yes, even connection requests that get rejected
    > consume bandwidth and CPU time that could be better spent doing real
    > work!) Of course, if it's your business LAN then that's what your
    > firewall is supposed to do. Now, if we could just get a lot of other
    > people, Comcast among them to do this SPAM would just go away!!
    >


    Yes, it's my home router, a Linksys BEFSR81. My home network is all the
    network I have these days.

    I used to use a software firewall but I've found it's not necessary.

  15. Re: Current status?

    Bill Gunshannon wrote:

    > So how is this different from just using port 25?


    587 allows an ISP to block port 25 connections to/from foreign IPs and
    their customers, reducing the problem of Windows PCs sneding out
    billions and billions of advertisements for magic pills.

    587 also allows an ISP to grant customers access to the ISP's SMTP
    services from the outside (wifi hotspots, mobile services) and thus
    makes it simpler for customers to move about without changing configs.

    With port 25, it becomes harder to do this because at the time of the
    HELO stage, the receiving SMTP server doesn't yet know whether the call
    is for inbound email (no relay) or whether it is a customer accessing
    from the outside, requiring authentication to enable relay.



  16. Re: Current status?

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

    > The situation is simple really:
    >
    > Both 25 and 587 use SMTP.
    >
    > The difference:
    >
    > Port 25 is used to get calls from the outside for messages to be
    > delivered to the inside. You can't require authentication for those. And
    > for those calls, you do not accept to relay mail to another outside address.


    TCPIP SET CONF SMTP/OPT=NORELAY

    > Port 587 is used to accept emails coming from the inside without
    > authentication, and you allow relaying. (aka: sending to the outside
    > world).


    Another approach is to relay only for certain IP addresses. I have
    never used it, but HP TCPIP I believe can be configured to do this. The
    SMTP relay server I use to send to the outside world uses this approach
    as well. (I have a dynamic IP address, but the person running the SMTP
    relay server also handles my DNS, so he knows who I am).


  17. Re: Current status?

    On Sep 8, 10:54*am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
    > But I
    > expect most here are not in the least bit interested.


    Perhaps we've all been reading everything, and don't need you to
    repost it or point it out for us.

    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.

    If I want to send spam and am prohibited from sending it to an MTA
    other than my local MTA, then I would either:

    a) Send it there. Any decent malware that infects my workstation can
    readily determine the address of my local MTA.

    or

    b) Establish my own properly authorized and configured MTA, with
    ARIN's blessing. Even if all MTA service providers were required to
    be registered it wouldn't stop someone from going ahead and
    registering. It would be pretty difficult or administratively
    prohibitive to try and distinguish between "legitimate" bulk e-mailers
    and spammers. The post office doesn't prevent anyone from sending 10s
    of thousands of junk mail flyers as long as the fee is paid, and I
    suspect any organized e-mail transfer infrastructure would end up
    doing the same.

  18. Re: Current status?

    Phillip Helbig---remove CLOTHES to reply wrote:

    > Another approach is to relay only for certain IP addresses.


    Yes, notably allow relaying when connections come from within your LAN.

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

  19. Re: Current status?

    In article ,
    FrankS writes:
    > On Sep 8, 10:54*am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
    >> But I
    >> expect most here are not in the least bit interested.

    > Perhaps we've all been reading everything, and don't need you to
    > repost it or point it out for us.
    > 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.


    No, what you have seen here lately is not my "social" solution it is
    merely a suggestion that proper use of the network as it was designed
    could eliminate the majority of the current SPAM.

    > If I want to send spam and am prohibited from sending it to an MTA
    > other than my local MTA, then I would either:
    > a) Send it there. Any decent malware that infects my workstation can
    > readily determine the address of my local MTA.


    And, it is the function of your local MTA to not allow that. And
    that is where we start getting into the "social" solution.

    > or
    > b) Establish my own properly authorized and configured MTA, with
    > ARIN's blessing. Even if all MTA service providers were required to
    > be registered it wouldn't stop someone from going ahead and
    > registering. It would be pretty difficult or administratively
    > prohibitive to try and distinguish between "legitimate" bulk e-mailers
    > and spammers.


    Again, this logic is why a "social" solution is needed.

    > The post office doesn't prevent anyone from sending 10s
    > of thousands of junk mail flyers as long as the fee is paid, and I
    > suspect any organized e-mail transfer infrastructure would end up
    > doing the same.


    The PO sells that specific service. It is generally held that sending
    junk mail does not incur any real cost on the recipient. Junk Email
    is quite different.

    In both cases above it would be a very short interval before no other
    legitimate MTA was willing to accept email from yours. And that would
    result in your loosing not only your SPAMer business but all your
    legitmate customers as well. No one is going to sign up for your
    service once they find out that they cannot send email to anyone
    and no one else will forward email to your MTA.

    My real solution would take this to the next level. :-)

    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

  20. Re: Current status?

    In article <48c5753e$0$12387$c3e8da3@news.astraweb.com>,
    JF Mezei writes:
    > Bill Gunshannon wrote:
    >
    >> So how is this different from just using port 25?

    >
    > 587 allows an ISP to block port 25 connections to/from foreign IPs and
    > their customers,


    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.

    > reducing the problem of Windows PCs sneding out
    > billions and billions of advertisements for magic pills.


    Just block outgoing port 25 for all addrfesses in yur domain except your
    MTA. Problem solved.

    >
    > 587 also allows an ISP to grant customers access to the ISP's SMTP
    > services from the outside (wifi hotspots, mobile services) and thus
    > makes it simpler for customers to move about without changing configs.


    That's fine if you want to do that. But it has nothing to do with wether
    or not port 25 should be blocked from regular use.

    >
    > With port 25, it becomes harder to do this because at the time of the
    > HELO stage, the receiving SMTP server doesn't yet know whether the call
    > is for inbound email (no relay) or whether it is a customer accessing
    > from the outside, requiring authentication to enable relay.


    If they are outside, and the IP addrfess is not in your addrfess block,
    they are no longer your customer. Now, if you want to accomodate them
    by all means, open up port 587. But that is a totally different thing
    and has no bearing on how port 25 should be handled.

    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

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast