Re: Setting up email on Slack 11.0 - Slackware

This is a discussion on Re: Setting up email on Slack 11.0 - Slackware ; +Alan Hicks+ wrote: > SMTP + painlessly = NULL I disagree. I think I proposed a method that would permit the OP to setup local SMTP service, with service to and from the Internet, with rather painless maintenance. In fact, ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: Setting up email on Slack 11.0

  1. Re: Setting up email on Slack 11.0

    +Alan Hicks+ wrote:

    > SMTP + painlessly = NULL


    I disagree. I think I proposed a method that would permit the OP to
    setup local SMTP service, with service to and from the Internet, with
    rather painless maintenance. In fact, the setup for what I propose is
    rather painless, though not effortless.

    What he's asking for can be accomplished painlessly, but it simply needs
    to be approached carefully, with the goal of not exposing local systems
    to more Internet access than necessary.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  2. Re: Setting up email on Slack 11.0

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2007-10-09, Sylvain Robitaille wrote:
    > +Alan Hicks+ wrote:
    >
    >> SMTP + painlessly = NULL

    >
    > I disagree. I think I proposed a method that would permit the OP to
    > setup local SMTP service, with service to and from the Internet, with
    > rather painless maintenance. In fact, the setup for what I propose is
    > rather painless, though not effortless.
    >
    > What he's asking for can be accomplished painlessly, but it simply needs
    > to be approached carefully, with the goal of not exposing local systems
    > to more Internet access than necessary.


    Touche. Perhaps I didn't make my point clearly. SMTP is not something
    anyone should just up and do without first learning about the wide
    world of mail.

    While there are both hard and easy ways to do this, no way is to me
    "easy" or "painless" as there's really nothing "easy" about SMTP; no
    matter what you think you know about it, there's something that you're
    wrong about or have never heard about.

    - --
    It is better to hear the rebuke of the wise,
    Than for a man to hear the song of fools.
    Ecclesiastes 7:5
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHC68MrZS6hX/gvjoRAkqiAKCCCeFgLyRRF7LQgPOmJ0gzfq1ITACgjjo1
    WxIi4i9x1M07YZbJ3yHmkYA=
    =rBoQ
    -----END PGP SIGNATURE-----

  3. Re: Setting up email on Slack 11.0

    +Alan Hicks+ wrote:

    > While there are both hard and easy ways to do this, no way is to me
    > "easy" or "painless" as there's really nothing "easy" about SMTP; ...


    Ah, but the OP wasn't asking for "easy", he was asking for "painless".
    :-)

    I don't think I could have given him "easy", though I do believe I
    suggested "least difficult", or at least "least aggravation". :-)

    As for SMTP itself, things don't get much easier: it's a text-based
    protocol with a small set of commands. Each of the commands has a very
    simple syntax. That's quite easy. The trouble usually comes from the
    fact that it's much easier to configure an SMTP server incorrectly than
    it is to configure it correctly.

    > no matter what you think you know about it, there's something that
    > you're wrong about or have never heard about.


    It's not *that* bad. I've been doing mail for nearly ten years, and yes
    there are a lot of things to keep in mind, and a few gotchas hiding
    behind corners (and plenty I've never heard about, or never needed to
    learn thoroughly enough to not be "wrong" about), but it *is* possible
    to step back and understand the problem being solved, and work towards a
    solution that will avoid the traps. The trick is to understand the
    problem in the context of email.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  4. Re: Setting up email on Slack 11.0

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2007-10-09, Sylvain Robitaille wrote:
    > As for SMTP itself, things don't get much easier: it's a text-based
    > protocol with a small set of commands. Each of the commands has a very
    > simple syntax. That's quite easy. The trouble usually comes from the
    > fact that it's much easier to configure an SMTP server incorrectly than
    > it is to configure it correctly.


    And from the fact that there are numerous extensions to these base
    commands, and lots of these commands are not well documented.

    >> no matter what you think you know about it, there's something that
    >> you're wrong about or have never heard about.

    >
    > It's not *that* bad. I've been doing mail for nearly ten years, and yes
    > there are a lot of things to keep in mind, and a few gotchas hiding
    > behind corners (and plenty I've never heard about, or never needed to
    > learn thoroughly enough to not be "wrong" about), but it *is* possible
    > to step back and understand the problem being solved, and work towards a
    > solution that will avoid the traps. The trick is to understand the
    > problem in the context of email.


    The trouble to me isn't so much knowing how mail is *supposed* to work,
    but instead knowing how it *actually* works. There are so many broken
    clients, so many different implimentations of SASL, so many different
    delivery agents, so many different spam deterents, so many different...
    you get the picture.

    SMTP in itself isn't hard. Setting up a mail server six years ago when
    I got started in this business was (and continued to be) a lot harder
    than it was 15 years ago. Spam wasn't a problem. Authenticating SMTP
    wasn't a problem (nearly everyone relayed for everyone else as a sort
    of courtesy). Clients still largely read mail straight from the local
    spool instead of via POP3 or IMAP.

    I guess my point is that "mail" in general has grown far beyond its
    original intentions. No one imagined it would be this big or have the
    problems it has today. The base SMTP protocol was never designed to
    consider spam. It has been extended far beyond its original vision,
    and no two implimentations do things the same way.

    - --
    It is better to hear the rebuke of the wise,
    Than for a man to hear the song of fools.
    Ecclesiastes 7:5
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFHDR6jrZS6hX/gvjoRAunAAJ9l3yrU+MWw/MYjGIUKWL0onzixWgCeOxEJ
    0zlWcaE2utheTImcXpbhIZE=
    =q3+a
    -----END PGP SIGNATURE-----

  5. Re: Setting up email on Slack 11.0

    +Alan Hicks+ wrote:

    > The trouble to me isn't so much knowing how mail is *supposed* to work,
    > but instead knowing how it *actually* works.


    In my experience, it mostly works just as it's supposed to ...

    > There are so many broken clients, so many different implimentations of
    > SASL, so many different delivery agents, so many different spam
    > deterents, so many different... you get the picture.


    Most of these things aren't as relevant to mail in general (and certainly
    not the problem discussed in this thread in particular), though. Broken
    mail clients? Worry about the ones that work correctly. Consider the
    broken ones "unsupported". If users insist on using broken software,
    they should expect broken behaviour, (... and no I will *not* break
    my mail configuration to accomodate your broken mail client ... fix or
    replace the client!)

    Mostly, though, "broken" mail clients that I've had any experience dealing
    with pose problems by obscuring details that the user might need (hard
    to get at message headers, obscuring the boundary between email and other
    net services, etc.) They work fine from the point of view of a mail
    admin (looking at handling the mail, not the UI).

    For it's part, SASL doesn't actually have anything to do with email
    (directly). It's an authentication layer, and it could (theoretically
    at least) be applied to any number of net services. More important
    to email is a good understanding of DNS (which you didn't mention).
    SASL is just an add-on.

    Delivery agents are even more simple: what more do you need than
    procmail? (and if you don't even need that much, there's still
    /bin/mail, right?)

    > SMTP in itself isn't hard. Setting up a mail server six years ago
    > when I got started in this business was (and continued to be) a lot
    > harder than it was 15 years ago.


    It didn't have to be "harder", you just had to be more careful that you
    set it up "correctly" the first time, than you might have 15 years ago.
    There's a difference. The environment was more forgiving of errors 15
    years ago, but it isn't all that much more difficult to "do it right"
    now than it was then.

    > Spam wasn't a problem.


    Spam was less of a problem. It was indeed a problem.

    > Authenticating SMTP wasn't a problem (nearly everyone relayed for
    > everyone else as a sort of courtesy).


    Not exactly. Client systems were still expected to submit messages to
    the appropriate mail servers. It's just that other mail servers would
    still have accepted to deliver messages.

    > Clients still largely read mail straight from the local spool instead
    > of via POP3 or IMAP.


    POP was a lot more prevalent 15 years ago than you might realize, though
    yes, reading from local mail spools was the more likely scenario.

    > I guess my point is that "mail" in general has grown far beyond its
    > original intentions.


    The intention is the same: deliver correspondance between users.

    The details have changed somewhat: try to identify and intercept unwanted
    "correspondance" while delivering the wanted correspondance.

    > No one imagined it would be this big or have the problems it has
    > today.


    Perhaps no one imagined the problems that have come up, but I'm quite sure
    the growth was indeed imagined. As for problems it has today, are there
    any problems with email today that we weren't dealing with 5 years ago?
    How about 10 years ago? I would say not. We're dealing with an ever
    increasing volume of the same types of problems, but increasing volume
    was a problem then too.

    My point is that setting up mail service is not black magic, and it
    isn't cryptic or frightful. There are issues that need to be
    understood, and usually site-specific problems that need to be resolved.
    These can be (and often are) understood in the context of how to provide
    reliable mail service for any given site. Some sites are better at it
    than others, but that reflects on the personnel at the sites, not the
    complexity of the service.

    When in doubt, keep things simple. Mail rarely needs to be very
    complicated, and even the complicated setups are best achieved by
    starting with a simple "base".

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  6. Re: Setting up email on Slack 11.0

    +Alan Hicks+ says:

    pgp trash troll delete

    Either put your pgp trash in the headers or dispense with the
    affectation altogether.

    Bugger off.

    cordially, as always,

    rm

+ Reply to Thread