[RBL] Current status? - VMS

This is a discussion on [RBL] Current status? - VMS ; 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, ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 76

Thread: [RBL] Current status?

  1. Re: Current status?

    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

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

  2. Re: Current status?

    In article ,
    Jan-Erik Söderholm writes:
    > Phillip Helbig---remove CLOTHES to reply wrote:
    >
    >> such
    >> machines on dial-up, volatile IP addresses are the main source of spam,

    >
    > I do have a hard time thinking that *dial up* has
    > that much to do with modern spam, has it ?


    The term "dial-up" today pretty much refers to any host that get's
    its address dynamically. No machine that gets it's address dynamically
    should be trying to send email to anyone other than its own internal
    MTA. Most legitimate email MTA's will refuse a connection from a
    machine from outside their domain that can be determined to be using
    a dynamically assigned ip address.

    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

  3. Re: Current status?

    In article ,
    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    > In article
    > <8c328cb8-33b0-42e2-b590-5aab5a7b2670@w1g2000prk.googlegroups.com>,
    > johnwallace4@yahoo.co.uk writes:
    >
    >> Enforcing "email from recognised SMTP servers only" would indeed get
    >> rid of much spam instantly, and is a tactic already used by some folks
    >> to reject *incoming* mail, but it would also break hundreds of little
    >> convenience Windows apps that have their own mailsenders built in, and
    >> inconvenience millions of their users. Log watchers, webcam watchers,
    >> etc, anything which sends notification by email when something
    >> "interesting" happens, using its own built-in mail server; they would
    >> all need their user/installer to actually know their ISP's SMTP server
    >> address so they could do the setup properly. How many PC users
    >> actually know or care much about that kind of thing?

    >
    > Perhaps true. On the other hand, such machines are the source of most
    > SPAM today, taken over by viruses etc sending spam without the owner
    > knowing, and without sending too many from one machine within a given
    > time (a characteristic some folks used to use to identify possible
    > sources of spam). I


    Which is why something as simple as the ISP blocking outgoing traffic
    to any addrfess wirth port 25 for all internal machines other than thier
    MTA is a good idea and would eliminate the largest source of SPAM.

    > think it would be a good idea that if such little
    > convenience apps were to be used, the user would have to enter the name
    > of a mailserver.


    It should not even be thier choice. Either send tot he local MTA or
    have the connection blocked. It's really that simple!!

    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?

    Jan-Erik Söderholm wrote:
    >>> 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.


    The DNS lookup will tell it the SMTP server of the *destination*
    ISP, not the originating ISP. It needs to do the MX lookup
    on the sender address, but even that is often not correct, since
    many ISPs and other businesses use a different server for outbound
    mail than for inbound mail.

    MX records exist so that external mail servers can find the
    domain's inbound servers, not so that internal mail clients
    can find the domain's outbound servers.

    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. I think some random windows programs
    peek into the Outlook configuration to try to determine the
    SMTP server, but if you are using some other mail client on
    the PC, that probably won't work or may provide a bogus or
    obsolete answer.

    The SMTP server should be happy to relay mail on behave of
    any client within the originating domain, but many have
    additional sanity checks to try to limit SPAM, such as
    making sure the various "sender" names are valid etc.
    Right now, I'm fighting with configuring a system at a
    customer site that wants to send problem notification emails
    to various people at the customer, and also to our support
    department and (possibly) to our support department's home
    email addresses and to our pager service. (We want to get
    notified even if our mail server is down.) The customer's
    outbound SMTP server will relay mail from "username@host.domain.com",
    but not from "username@domain.com" unless "username" is a valid mail
    recipient at domain.com. However, many external SMTP servers
    won't take mail from "@host.domain.com" since the customer's
    internal DNS isn't visible to the outside world. (The
    address and ptr records for the SMTP servers are externally
    visible, but thousands of internal servers, workstations, PCs,
    routers, etc. are not.) So the bottom line is I can send
    mail from "username@host.domain.com" to one support person's
    home email which is @gmail.com, but not to my home email
    which is @verizon.net. (I've white-listed "*.domain.com"
    on our external email service, so the client system can
    send to "username@egh.com") On the other hand, I can send
    mail from "known.user@domain.com" to anyone in the world (that I've
    tried so far), but "known.user" has to be a known email user at
    domain.com, or the customer's SMTP server won't forward it.
    (I can't send directly to the destination SMTP server because
    the customer's firewall blocks outbound SMTP except from their
    outbound servers.)

    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", but I haven't figured out how to make
    it send from "known.user" instead of "username". 2) I don't
    want to use an existing customer employee's email username
    (such as the sytem administrator's username) because I don't
    want them getting annoyed with bounces, etc., especially
    while testing it. Also, if the employee gets reassigned,
    the mail would no longer be relevent to them, and if they
    leave the company, the email address will most likely no
    longer be valid. (It's pretty much a turnkey system, which
    means the customer handles day-to-day operations, but we
    deal with anything exceptional, such as crashes and hardware
    or software failures.) So I need to get the customer's
    network/mail people to supply us with a fake email address
    and to forward bounces, undeliverable mail, etc. somewhere
    useful (like back to us) so we know when somethings gone
    wrong.

    Actually, 3 problems, since right now no one can respond
    to mail from "user@host.domain.com" (though I think we can
    jam a "reply-to:" header into the mail to fix this.)

    Actually 4 problems, since the VMS V8.3 version of MIME
    seems to be broken; one of the things we want to automail
    is reports in the form of comma-separated lists that
    can be imported into a spread-sheet by the recipient,
    but MIME is messing them up somehow. (The MIME V1.8 in Alpha
    V7.3-2 seems to work okay, both with UCX and TCPware,
    but I think the current MIME V1.93 on both Itanium and
    Alpha is sticking a blank line in the headers somewhere...)


    >
    > Why whould anything just needing to *send* a mail have a
    > smtp *server* implementation ?


    Because relaying mail is the principle function of an SMTP
    server?

    >
    > Jan-Erik.



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

  5. Re: Current status?

    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.

    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.


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

  6. Re: Current status?

    In article <6ib9tbFpklicU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >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.


    Totally agree.

    >MTA's are the machines with the MX record in tghe DNS system.


    Not necessarily. Many organisations have separate MTAs for incoming and
    outgoing mail. Only those which accept incoming mail are listed in the DNS MX
    records.

    As well as blocking connections to port 25 on external systems from your
    internal systems (apart from for your designated MTAs) you should also
    block connections from the external world to your internal systems on port 25
    (apart again from your designated MTAs). This stops someone setting up an
    internal system as an MTA which sends out through your designated MTAs.
    Because such systems are often poorly configured and are accessible from the
    outside world they maybe open-relays and because they send out through your
    designated MTAs they may cause your MTAs to be listed as "secondary"
    open-relays on certain blacklists.


    David Webb
    Security team leader
    CCSS
    Middlesex University




    > 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
    >
    >--
    >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: Current status?

    In article ,
    =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?=
    writes:

    > Phillip Helbig---remove CLOTHES to reply wrote:
    >
    > > such
    > > machines on dial-up, volatile IP addresses are the main source of spam,

    >
    > I do have a hard time thinking that *dial up* has
    > that much to do with modern spam, has it ?


    OK, not real dialup with the acoustic modem, but in the sense of "I want
    to go online now; my provider should give me an IP address", which
    probably takes place via DSL in most cases today.


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

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


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

    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.

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


    David Webb
    Security team leader
    CCSS
    Middlesex University


    >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.
    >
    >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.
    >
    >
    >--
    >John Santos
    >Evans Griffiths & Hart, Inc.
    >781-861-0670 ext 539


  9. Re: Current status?

    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?

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


    DEFINE TCPIP$SMTP_FROM ?


  10. Re: Current status?

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

    > As well as blocking connections to port 25 on external systems from your
    > internal systems (apart from for your designated MTAs) you should also
    > block connections from the external world to your internal systems on port 25
    > (apart again from your designated MTAs). This stops someone setting up an
    > internal system as an MTA which sends out through your designated MTAs.
    > Because such systems are often poorly configured and are accessible from the
    > outside world they maybe open-relays and because they send out through your
    > designated MTAs they may cause your MTAs to be listed as "secondary"
    > open-relays on certain blacklists.


    I receive email locally on my VMS cluster, so the outside world has to
    be able to connect. Misusing me as a relay? Not a problem:

    SMTP Configuration

    Options
    Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
    Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
    Maximum interval: 3 00:00:00.00 HEADERS

    I think NORELAY is even the default.


  11. Re: Current status?

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

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


    What's missing?


  12. Re: Current status?

    In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >In article , david20@alpha2.mdx.ac.uk
    >writes:
    >
    >> As well as blocking connections to port 25 on external systems from your
    >> internal systems (apart from for your designated MTAs) you should also
    >> block connections from the external world to your internal systems on port 25
    >> (apart again from your designated MTAs). This stops someone setting up an
    >> internal system as an MTA which sends out through your designated MTAs.
    >> Because such systems are often poorly configured and are accessible from the
    >> outside world they maybe open-relays and because they send out through your
    >> designated MTAs they may cause your MTAs to be listed as "secondary"
    >> open-relays on certain blacklists.

    >
    >I receive email locally on my VMS cluster, so the outside world has to
    >be able to connect. Misusing me as a relay? Not a problem:
    >
    >SMTP Configuration
    >
    >Options
    >Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
    >Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
    >Maximum interval: 3 00:00:00.00 HEADERS
    >
    >I think NORELAY is even the default.
    >

    In which case your system should either

    1) Be one of your designated MTAs
    or
    2) Send and receive its mail through your organisations designated MTAs

    NORELAY may be good enough - I haven't really looked at a UCX SMTP
    configuration in almost a decade. But if your mailserver was just one of a large
    number in a big domain which I was responsible for I wouldn't want to rely on
    you and all those others outside my direct control having set them up correctly
    to prevent inappropriate relaying.

    At Middlesex University we were getting lots of people (especially in the
    computer science department) setting up a Linux or other server and just
    installing Sendmail or another mailserver. Before we put in the above block
    (a longtime ago now) we were getting such internal mailservers setup without
    notice fairly regularly and lots of them were badly configured and open-relays.


    David Webb
    Security team leader
    CCSS
    Middlesex University



  13. Re: Current status?

    In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >In article , david20@alpha2.mdx.ac.uk
    >writes:
    >
    >> 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.

    >
    >What's missing?
    >

    A quick list from my knowledge of UCX SMTP compared to PMDF

    Generic address rewriting for centralised naming etc
    Callouts to antivirus/anti-spam products (content scanning products etc)
    SMTP AUTH/SASL both client and server
    LDAP lookups
    Support for SMTP SUBMISSION
    SPF/SRS
    SMTP/TLS (though this is an extra cost item for non-hobbyists)
    Ability to setup separate channels with different options for sending to
    different MTAs
    Header trimming
    Addition of own headers


    (
    I can't remember does UCX SMTP server support EHLO responses such as SIZE ?
    TCPWARE and MULTINET probably do but I'm not sure about TCPIP Services.
    )

    That is just a few off the top of my head. The SMTP Servers which come with
    the TCPIP stacks are just meant to be very simple systems which receive mail for
    local users and send mail from local users. A fully fledged MTA can also act as
    a central mailhub which directs mail to multiple internal and external systems
    in a controlled manner. They are much larger more flexible systems.


    David Webb
    Security team leader
    CCSS
    Middlesex University




  14. Re: Current status?

    david20@alpha2.mdx.ac.uk wrote:

    > The SMTP Servers which come with
    > the TCPIP stacks are just meant to be very simple systems which receive mail for
    > local users and send mail from local users.


    OK.
    And if *that* is what you need, would you say that the
    smtp parts of TCPIP Services are OK as-is ?

  15. Re: [RBL] Current status?

    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.

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


  16. Re: Current status?

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

    > >I receive email locally on my VMS cluster, so the outside world has to
    > >be able to connect. Misusing me as a relay? Not a problem:
    > >
    > >SMTP Configuration
    > >
    > >Options
    > >Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
    > >Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
    > >Maximum interval: 3 00:00:00.00 HEADERS
    > >
    > >I think NORELAY is even the default.
    > >

    > In which case your system should either
    >
    > 1) Be one of your designated MTAs
    > or
    > 2) Send and receive its mail through your organisations designated MTAs


    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. Anyone
    can try send email to this, as far as I'm concerned. (I could have the
    highest-priority record point to another MX server---which I use only as
    backup servers, which kick in when I am not directly reachable---but
    this has the disadvantage that these servers would have to accept mail
    to non-existent users on my system which, when delivered to me, would
    bounce; most of this would create backscatter spam.) Most connection
    attempts to it, however, are dropped because the source is in an RBL.


  17. 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.
    >
    > I can't really fault a COTS vendor for sending email via SMTP.
    >

    Your "security experts" are talking nonsense. SMTP is used to send mail
    both MUA to MTA and MTA to MTA.

    POP and IMAP cannot be used to send mail since that is NOT their function.
    POP and IMAP just connect to a mail store and access or manipulate mail.

    The MUA should be configured to send via the organisations local MTA usually
    referred to as configuring the mail client to send via a smarthost.

    David Webb
    Security team leader
    CCSS
    Middlesex University


  18. Re: Current status?

    In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >In article , david20@alpha2.mdx.ac.uk
    >writes:
    >
    >> >I receive email locally on my VMS cluster, so the outside world has to
    >> >be able to connect. Misusing me as a relay? Not a problem:
    >> >
    >> >SMTP Configuration
    >> >
    >> >Options
    >> >Initial interval: 0 00:30:00.00 Address_max: 16 EIGHT_BIT
    >> >Retry interval: 0 01:00:00.00 Hop_count_max: 16 NORELAY
    >> >Maximum interval: 3 00:00:00.00 HEADERS
    >> >
    >> >I think NORELAY is even the default.
    >> >

    >> In which case your system should either
    >>
    >> 1) Be one of your designated MTAs
    >> or
    >> 2) Send and receive its mail through your organisations designated MTAs

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


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

    (You mention the WAN address of your LAN which suggests that you probably have
    an internal network which is using dynamic NAT. Hence NAT is probably taking
    care of stopping direct external connections to your other internal systems on
    port 25 anyway.)

    David Webb
    Security team leader
    CCSS
    Middlesex University


    > Anyone
    >can try send email to this, as far as I'm concerned. (I could have the
    >highest-priority record point to another MX server---which I use only as
    >backup servers, which kick in when I am not directly reachable---but
    >this has the disadvantage that these servers would have to accept mail
    >to non-existent users on my system which, when delivered to me, would
    >bounce; most of this would create backscatter spam.) Most connection
    >attempts to it, however, are dropped because the source is in an RBL.
    >


  19. Re: Current status?

    In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
    >david20@alpha2.mdx.ac.uk wrote:
    >
    >> The SMTP Servers which come with
    >> the TCPIP stacks are just meant to be very simple systems which receive mail for
    >> local users and send mail from local users.

    >
    >OK.
    >And if *that* is what you need, would you say that the
    >smtp parts of TCPIP Services are OK as-is ?


    Strange question. Obviously if a program provides all that you need then
    that program is OK for your needs.
    For my needs at the University with systems acting as central mailhubs the
    functionality of PMDF is much better. For my hobbyist system at home I might be
    able to live with the reduced functionality of one of the TCPIP stacks' SMTP
    servers but ancillary features of PMDF such as the ability of PMDF MAIL to
    send MIME mail without having to mess around with external MIME tools etc tip
    the balance firmly in favour of using PMDF.

    Or are you asking whether the SMTP server provided by TCPIP services works
    properly ? Since I haven't used it in anger for over ten years I can't really
    comment upon how well it works.


    David Webb
    Security team leader
    CCSS
    Middlesex University

  20. Re: Current status?

    david20@alpha2.mdx.ac.uk wrote:

    > Or are you asking whether the SMTP server provided by TCPIP services works
    > properly ? Since I haven't used it in anger for over ten years I can't really
    > comment upon how well it works.


    The SMTP server on VMS has one good thing others may not have: the
    ability to trace/log the 821 dialogue between two MTAs. So when one
    server refuses your messages, you can trace the dialogue and try to see why.

    Unfortunatly, this feature is useful/needed because the TCPIP Services
    SMTP server never returns the real error codes issued by the remote
    server, it generates its own absolutely useless error codes.

    The receiver's SPAM features (IP blocks RBLs and need to have reverse
    transaltion is sufficient for me. But lack of authentication capability
    on the receiver is a real drawback.

    I'd say that the TCPIP Services SMTP server/receiver are far from being
    enterprise ready. Postfix, which comes even on Mac desktops is a far
    more enterprise ready SMTP server.


    And I do not believe HP has any plans to seriously improve the SMTP server.

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