Slackware 11.0 dialup, mail, user groups - Slackware

This is a discussion on Slackware 11.0 dialup, mail, user groups - Slackware ; On Sun, 17 Jun 2007 23:48:16 +0000, rm wrote: > If you don't know what you are talking about, you shouldn't be > giving advice in this newsgroup. That's right, so stop posting immediately. > If you are trying to ...

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

Thread: Slackware 11.0 dialup, mail, user groups

  1. Re: Slackware 11.0 dialup, mail, user groups

    On Sun, 17 Jun 2007 23:48:16 +0000, rm wrote:

    > If you don't know what you are talking about, you shouldn't be
    > giving advice in this newsgroup.


    That's right, so stop posting immediately.

    > If you are trying to learn, then listen with respect.


    Har! HAR!!! LOL, that's a good one.

    > cordially, as always,


    Smeg off.


    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me".


  2. Re: Slackware 11.0 dialup, mail, user groups

    On Mon, 18 Jun 2007 01:12:50 +0000, rm wrote:

    > For your part, you have ignored our solution. You have ignored our
    > objective critique of your solution. But you did accuse us of
    > throwing a "tantrum."
    >
    > Why is that?


    Probably because it's fun to watch you speak as "we" and "us", when
    everyone knows it's just all the various voices you hear in your head.

    It's like watching a retarded puppy play with a butterfly. Amusing.



    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me".


  3. Re: Slackware 11.0 dialup, mail, user groups

    rm@biteme.org wrote:

    > Tantrums?


    Yes. Read your followups to messages from others that agreed with the
    approach I suggested (call sendmail from ip-up to process outbound mail
    queues).

    > We disagreed with you. And we explained, in detail, over several
    > posts, why we believed that we offered the best solution and we
    > described why your solution was not the best.


    I have no objection to your disagreement or your pointing out that you
    don't believe the approach I proposed to be as good as what you
    proposed. Don't look only at _what_ you said; consider _how_ you said
    it. It was one or more tantrums, looking at it from here.

    > For your part, you have ignored our solution.


    Because I didn't dispute it, I ignored it? I happen to believe a
    different approach would provide a more general solution that would
    scale better to more than just the OP's own outbound mail.

    > You have ignored our objective critique of your solution.


    There's no point in disputing it. You disagree with it on the basis
    that you believe it's more complex than necessary. You're allowed. Why
    would I want to go around in circles with you over "is not!" "is too!"
    "is not!" ... ??? I don't care that you disagree with what I proposed
    or that you find it "too complex". I'm not trying to convince you of
    it, I'm simply trying to help the OP solve his problem.

    > If you are using your ISP's smarthost as your MTA that is good because
    > it is up all the time (hopefully).


    Whether the outgoing MTA is always available is completely beside the
    point. Whether the envelope sender address has a domain-name portion
    for which there is at least one MX available at any time is what matters.
    The ISP's mail server need not be that MX, but using the ISP's outbound
    mail relay can help reduce delivery problems in other ways (some sites
    refusing mail from dynamically addressed systems, for example, or ISPs
    not permitting outbound TCP/25). In fact, if the envelope sender is not
    set appropriately it makes no difference whatsoever if the ISP's mail
    relay is used to send the outgoing messages: bounces will go to limbo at
    best.

    > But the whole point of sendmail is that it is precisely a
    > "network-attached smtp daemon" to be used at all times.


    You're ignoring the fact that Sendmail is more than an SMTP daemon. It
    always has been.

    > That's what sendmail is for.


    That's not all Sendmail is for.

    > This is absolutely appalling behaviour.


    Feel free to ignore my messages in the future. Do I need to PGP-sign
    them for you to start ignoring them?

    > Mike's whole problem came about because he was confused and believed
    > that fetchmail and sendmail were sister programs and counterparts of
    > each other.


    Although that's one possible conclusion that can be reached from the
    original problem description, it isn't the only one, and Mike never
    actually _said_ he believed that to be the case. I prefer to base
    responses on what information has been provided, not on conclusions I
    might reach.

    Mike did, however, reach the correct conclusion that Sendmail would
    be the correct tool to send any outbound mail he had queued up, and
    apparently has done enough homework to understand how to call Sendmail
    to accomplish that. What he's missing is perhaps a little additional
    background on how that call should be done (not as an unprivileged user,
    so via the ip-up script is one possibility, and "as root" is another).

    > Why didn't you correct him?


    I believed I pointed him to further information that should have helped
    him. You attempted to give the man a fish, and I attempted to teach him
    how to fish. There's a difference in our perceptions of what kind of
    fish he's after is all.

    > What's more, sendmail will not even function properly if it is not in
    > full-time daemon mode, which is impossible on a casual dialup system.


    Sendmail has most certainly been used quite successfully in exactly that
    sort of situation. As a matter of fact, Sendmail got its start at a
    time when dialup between remote systems was a normal way of functioning.

    > You are most certainly free to point out the flaws in our solution.
    > In fact, we are quite disappointed that you didn't even try to do so.


    The most obvious flaws I see in what you've proposed is that not all
    mail that Mike might be interested in sending out is necessarily composed
    interactively by a human (think cron jobs as an obvious example).

    Secondly, your proposed approach is based on a perception that some MUAs
    are simply best avoided. I find that counterproductive, and offered
    a different approach that doesn't make any difference what software is
    being used to send the message, or how many different users use how many
    different MUAs. Not all people who post here looking for a solution to
    a problem are running a single-user home system, and not even all home
    systems are single-user systems. People usually don't want a solution
    that will work only if they're not using certain software, or worse only
    if they _are_ using certain software.

    Mike didn't indicate whether he wanted a single-user solution or a more
    general one that can be applied elsewhere. You offered a very specific
    single-user solution, and I offered one that generalizes better.

    I have absolutely no objection that you and I have offered significantly
    different approaches to the same problem, and I won't even make any
    claims about "better". I feel that what I've proposed is more general,
    in that it is not limitted to sending outbound mail from only one user
    at a time, and being able to "send" (submit for sending) a message
    only when the network connection is available. I think Mike should
    be permitted a chance to decide which approach he finds is "better"
    for his own situation.

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

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

  4. Re: Slackware 11.0 dialup, mail, user groups

    Following up to my own message ... I have more to add ...

    > I happen to believe a different approach would provide a more general
    > solution that would scale better to more than just the OP's own
    > outbound mail.


    More importantly, the OP didn't ask how he could accomplish what he was
    trying to do without using Sendmail. He wanted to know what he needed
    to do to process his queued outbound mail, and why his attempts to
    invoke Sendmail as an unprivileged user were failing.

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

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

  5. Re: Slackware 11.0 dialup, mail, user groups

    Sylvain Robitaille wrote:
    > rm@biteme.org wrote:
    >
    >> Tantrums?

    >
    > Yes. Read your followups to messages from others that agreed with the
    > approach I suggested (call sendmail from ip-up to process outbound mail
    > queues).
    >
    >> We disagreed with you. And we explained, in detail, over several
    >> posts, why we believed that we offered the best solution and we
    >> described why your solution was not the best.


    Don't see any tantrums.

    > I have no objection to your disagreement or your pointing out that
    > you don't believe the approach I proposed to be as good as what
    > you proposed. Don't look only at _what_ you said; consider _how_
    > you said it. It was one or more tantrums, looking at it from
    > here.


    How we say things isn't even relevant to the core issue, which of
    course, you haven't even mentioned so far. In any case, we are
    always cordial.

    Using sendmail on a dialup is asinine. We don't care if you don't
    like the way we put it.

    cordially, as always,

    rm

  6. Re: Slackware 11.0 dialup, mail, user groups

    Sylvain Robitaille wrote:
    > Following up to my own message ... I have more to add ...
    >
    >> I happen to believe a different approach would provide a more general
    >> solution that would scale better to more than just the OP's own
    >> outbound mail.

    >
    > More importantly, the OP didn't ask how he could accomplish what he was
    > trying to do without using Sendmail.


    That's probably because he believed that he had no choice but to use
    sendmail.

    > He wanted to know what he needed to do to process his queued
    > outbound mail, and why his attempts to invoke Sendmail as an
    > unprivileged user were failing.


    No, he wanted to know how to ensure that his emails went out on
    demand, before he hung up. He was not able to make this as clear as
    he liked because he misunderstood the issue. If you read his
    postings it is clear that he believed that sendmail was a sister app
    to fetchmail, which is totally reasonable, on the face of it.

    cordially, as always,

    rm

  7. Re: Slackware 11.0 dialup, mail, user groups

    On Jun 16, 8:42 pm, Sylvain Robitaille
    wrote:
    > look into the ip-up script (/etc/ppp/ip-up on a typical Slackware
    > installation). You'll find details about that in the pppd manual page.


    Thanks for the pointer here Sylvain, ip-up/down works for me.

    > on-demand dialing, so that when there is a mail message ready to go (and


    I had diald running by default on some version of linux I was running
    once I forget which.
    Very disconcerting for the modem to come on-line while I'm on the
    phone, likewise to hear
    the computer dialing out when I haven't asked it to.

    > I think the mistake you're making, fundamentally, is that you're looking
    > for ways to cause these things to happen manually, rather than looking
    > for ways to just let the computer do them for you.


    I use linux rather than windows because I want to drive the computer
    rather than be
    driven by it. Automatic rather than manual is fine by me as long as
    it's doing what I want
    done and I know where the controls are.
    I've restored mike's groups to stock except for adm which he has for
    other reasons and
    the mail still moves. I'll unwind the rest of the changes eventually.
    Thanks for your help,
    Mike



  8. Re: Slackware 11.0 dialup, mail, user groups

    Mike trolled:
    > On Jun 16, 8:42 pm, Sylvain Robitaille
    > wrote:


    >> look into the ip-up script (/etc/ppp/ip-up on a typical Slackware
    >> installation). You'll find details about that in the pppd manual
    >> page.


    > Thanks for the pointer here Sylvain, ip-up/down works for me.


    Another guy who likes building ships in bottles. You'll fit in well
    around here, lugan.

    >> on-demand dialing, so that when there is a mail message ready to go (and


    > I had diald running by default on some version of linux I was
    > running once I forget which. Very disconcerting for the modem to
    > come on-line while I'm on the phone, likewise to hear the computer
    > dialing out when I haven't asked it to.


    >> I think the mistake you're making, fundamentally, is that you're looking
    >> for ways to cause these things to happen manually, rather than looking
    >> for ways to just let the computer do them for you.


    > I use linux rather than windows because I want to drive the
    > computer rather than be driven by it.


    This is a popular fallacy. You are "driving" the bash shell, not
    linux. And the bash shell, or at least its predecessors, have been
    around since the 1970s.

    The biggest differences between driving linux with the bash shell
    and driving windows with its gui, are that the latter is much
    faster, much more intuitive, and much, much easier to setup.

    > Automatic rather than manual is fine by me as long as it's doing
    > what I want done and I know where the controls are. I've restored
    > mike's groups to stock except for adm which he has for other
    > reasons and the mail still moves. I'll unwind the rest of the
    > changes eventually.


    It's much easier to get at the controls of a windows setup than a
    linux setup. But you have been overwhelmed by the hype spewed by
    the great unwashed.

    There is a reason that people buy windows when linux is free. And
    it ain't because they're all stupid.

    > Thanks for your help,


    What, no thanks to us? We're the only one who gave you truly useful
    advice. Using sendmail in a single user system is horribly (not to
    mention, laughably) inefficient, and a pain in the ass. It's like
    building a ship in a bottle, and ok, if you're a hobbyist.

    In any case, some people like having hemmorhoids because that means
    they get to have fun applying the old Prep H. Make sure you have a
    good supply on hand.

    You'll learn. We've been doing this stuff longer than most around
    here.

    cordially, as always,

    rm

  9. Re: Slackware 11.0 dialup, mail, user groups

    On Wed, 20 Jun 2007 00:14:46 +0000, rm trolled:

    > The biggest differences between driving linux with the bash shell
    > and driving windows with its gui, are that the latter is much
    > faster, much more intuitive, and much, much easier to setup.



    ___________________
    /| /| | |
    ||__|| | Please do |
    / O O\__ NOT |
    / \ feed the |
    / \ \ trolls |
    / _ \ \ ______________|
    / |\____\ \ ||
    / | | | |\____/ ||
    / \|_|_|/ \ __||
    / / \ |____| ||
    / | | /| | --|
    | | |// |____ --|
    * _ | |_|_|_| | \-/
    *-- _--\ _ \ // |
    / _ \\ _ // | /
    * / \_ /- | - | |
    * ___ c_c_c_C/ \C_c_c_c____________



    --
    "Ubuntu" -- an African word, meaning "Slackware is too hard for me".


  10. Re: Slackware 11.0 dialup, mail, user groups

    On Wed, 20 Jun 2007 00:14:46 +0000, rm wrote:

    > Using sendmail in a single user system is horribly (not to
    > mention, laughably) inefficient, and a pain in the ass.


    rc.sendmail is one of the first things I make non-executable.

    I have always used pop3 mail via my ISP.
    I always configure kmail or sylpheed or thunderbird etc. to deal with my
    pop3 mail account and sendmail is never involved.

    My current email client is kmail.
    My isp is verizon.
    My pop3 server is incoming.verizon.net
    My smtp server is outgoing.verizon.net
    I configure kmail to submit my username and password automagically when I
    check for or send mail via kmail.
    There are no permissions issues.
    I have, in the past, configured fetchmail in conjunction with gkrellm to
    download my pop3 mail to my local box which would require me to configure
    kmail to use a local mailbox instead of pop3. I still would not need
    sendmail to send mail though.

    I have not seen anything the OP stated that would make me believe
    sendmail was a requirement for his needs or that any basic mail client
    functionality was less than what he required.

    In other words, until I see any info to the contrary, I agree with rm.

    Mike, did you ever state what email client you are trying (have tried) to
    use?











  11. Re: Slackware 11.0 dialup, mail, user groups

    Franklin wrote:

    > My current email client is kmail.
    > My isp is verizon.
    > My pop3 server is incoming.verizon.net
    > My smtp server is outgoing.verizon.net
    > I configure kmail to submit my username and password automagically
    > when I check for or send mail via kmail.


    Do you have an "always-on" connection? (DSL or cablemodem?)

    > There are no permissions issues.


    Right. I think we established already that the OP's problem with
    outgoing mail wasn't because of permissions (I suggested that the
    problem with fetchmail was likely due to a lack of permission to read
    /etc/resolv.conf, and although it wasn't clarified whether that was
    correct, that problem has since been resolved, and the only remaining
    problem was ensuring that queued up outbound mail could be sent).

    > I have, in the past, configured fetchmail in conjunction with gkrellm
    > to download my pop3 mail to my local box which would require me to
    > configure kmail to use a local mailbox instead of pop3. I still would
    > not need sendmail to send mail though.


    Again, are you referring to an always-on connection? The OP is using
    dialup with intermittent connectivity. I think it's reasonable for
    him to want to be able to compose messages and submit them for sending
    while his connection is not established (thus saving his telephone
    line for other uses), then have them all be sent automatically when the
    connection comes up (and new incoming mail picked up at the same time).
    It's what I believe he was trying to accomplish from the start, and what
    I believe he has ultimately accomplished.

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

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

  12. Re: Slackware 11.0 dialup, mail, user groups

    Sylvain Robitaille wrote:
    > Franklin wrote:
    >
    >> My current email client is kmail.
    >> My isp is verizon.
    >> My pop3 server is incoming.verizon.net
    >> My smtp server is outgoing.verizon.net
    >> I configure kmail to submit my username and password automagically
    >> when I check for or send mail via kmail.

    >
    > Do you have an "always-on" connection? (DSL or cablemodem?)


    It doesn't make any difference.

    >> There are no permissions issues.

    >
    > Right. I think we established already that the OP's problem with
    > outgoing mail wasn't because of permissions (I suggested that the
    > problem with fetchmail was likely due to a lack of permission to read
    > /etc/resolv.conf, and although it wasn't clarified whether that was
    > correct, that problem has since been resolved, and the only remaining
    > problem was ensuring that queued up outbound mail could be sent).


    >> I have, in the past, configured fetchmail in conjunction with gkrellm
    >> to download my pop3 mail to my local box which would require me to
    >> configure kmail to use a local mailbox instead of pop3. I still would
    >> not need sendmail to send mail though.


    > Again, are you referring to an always-on connection? The OP is using
    > dialup with intermittent connectivity.


    And that is precisely why he shouldn't be using sendmail which is
    designed to be run on a server. If he sends messages out and they
    bounce, then he is not going to receive error messages unless he
    happens to be logged in at the precise time those messages come to
    him. After the target server sends out messages for a short period
    of time, it will give up and it may very well be that he never
    receives an error message and he never learns that his emails did
    not go through.

    And you _know_ this. But you are loathe to admit it.

    Why?

    > I think it's reasonable for him to want to be able to compose
    > messages and submit them for sending while his connection is not
    > established (thus saving his telephone line for other uses), then
    > have them all be sent automatically when the connection comes up
    > (and new incoming mail picked up at the same time).


    Oh, so you think it preferable that he never knows if his messages
    go out or bounce or whatever? Or would you rather have him search
    logs to see if his messages "automatically" get sent out.
    Unfortunately those logs will never tell him if the messages he
    sends out are actually received.

    In a modern news client there are settings where you can make sure
    that messages are automatically sent out and received and you don't
    need fetchmail and you don't need sendmail.

    > It's what I believe he was trying to accomplish from the start,
    > and what I believe he has ultimately accomplished.


    So he has built a ship in a bottle. If he is using a modern news
    client (pretty much anything other than elm and mutt) then his
    silliness with fetchmail and sendmail are nothing more than complex
    redundancies. In fact, if he is going to use sendmail, there is no
    reason for him to even use fetchmail and a remote pop3 server. So
    that amounts to a redundancy within a redundancy. A recursive
    redundancy.

    We have lost a great deal of respect for your technical knowledge
    through this thread. Sendmail and fetchmail are obsolete in a
    single user system, dialup or otherwise. The ISP standard all over
    the world are pop3 and smtp servers, both of which are easily and
    quickly specified in the modern email client.

    Why don't you tell him to setup his own domain name and then change
    his dns servers each time his dialup dynamic ip address comes up
    differently so that he can use sendmail? That sounds like fun, eh?
    Of course he still won't get his error messages because sendmail
    will only be up an hour a day, but who cares about that?

    cordially, as always,

    rm

  13. Re: Slackware 11.0 dialup, mail, user groups

    Franklin wrote:
    >
    > I have not seen anything the OP stated that would make me believe
    > sendmail was a requirement for his needs or that any basic mail client
    > functionality was less than what he required.
    >
    > In other words, until I see any info to the contrary, I agree with rm.


    As far as I remember the OP didn't mention his needs or any reason
    why he decided to run sendmail. That would explain why you didn't see
    it; it was not the subject of this discussion.

    I agree that it is possible to have basic mail functionality (sending
    and receiving messages) without running sendmail or any other MTA, if
    your mail client has smtp-functionality to submit messages. But there
    still are valid reasons to run a local MTA.

    I prefer to run sendmail on all my systems (workstation at home,
    workstations and servers at work) for the following reasons:
    -- I need a MTA if I want to see (error-)output from cron-jobs.
    This was already mentioned by Sylvain.
    -- It allows me to easily send mail from scripts using the 'mail'
    command.
    -- It allows me to directly deliver mail to other users of the
    system, without sending it to the ISP's mail server and fetching
    it again.
    -- All outbound mail will pass sendmail (unless I configure a MUA
    to send directly to the ISP) so sendmail supplies a single
    configuration point. I only have to configure a smarthost and
    the translation from login_name@local.host.name to user@ips.domain
    in sendmail and it will apply to whatever MUA I chose without
    further configuration.

    If the resources used by the sendmail daemon are an issue: you can
    start sendmail from inetd (don't do that on high mail-volume systems).

    Yes, it is certainly possible to send an receive mail without running
    a MTA. But please don't bash people who do decide to run a MTA, even
    if you think their needs are as basic as yours.


    Regards,

    Kees.

    --
    Kees Theunissen.

  14. Re: Slackware 11.0 dialup, mail, user groups

    Kees Theunissen wrote:
    > Franklin wrote:
    >>
    >> I have not seen anything the OP stated that would make me believe
    >> sendmail was a requirement for his needs or that any basic mail client
    >> functionality was less than what he required.
    >>
    >> In other words, until I see any info to the contrary, I agree with rm.

    >
    > As far as I remember the OP didn't mention his needs or any reason
    > why he decided to run sendmail. That would explain why you didn't see
    > it; it was not the subject of this discussion.
    >
    > I agree that it is possible to have basic mail functionality (sending
    > and receiving messages) without running sendmail or any other MTA, if
    > your mail client has smtp-functionality to submit messages. But there
    > still are valid reasons to run a local MTA.


    Not on a dialup system. Only on a server.

    > I prefer to run sendmail on all my systems (workstation at home,
    > workstations and servers at work) for the following reasons:
    > -- I need a MTA if I want to see (error-)output from cron-jobs.
    > This was already mentioned by Sylvain.


    What cron jobs are you running on a dialup system? In any case, you
    can check logs for those records.

    > -- It allows me to easily send mail from scripts using the 'mail'
    > command.


    Easily? What is easy about sending email from scripts using the
    mail command?

    > -- It allows me to directly deliver mail to other users of the
    > system, without sending it to the ISP's mail server and fetching
    > it again.


    Well, if that's the case, then you are using a server, so go ahead
    and knock yourself out with sendmail.

    But the OP is talking about a single-user, dialup system, and none
    of the reasons you want sendmail running apply to his system.

    > -- All outbound mail will pass sendmail (unless I configure a MUA
    > to send directly to the ISP) so sendmail supplies a single
    > configuration point.


    And since the OP is a single user, he is already a single
    configuration point. In any case, instead of setting up individual
    users within a client, you are now stuck with setting up individual
    users with sendmail which isn't all that easy unless you are
    strictly local.

    > I only have to configure a smarthost and
    > the translation from login_name@local.host.name to user@ips.domain
    > in sendmail and it will apply to whatever MUA I chose without
    > further configuration.


    And how many MUAs do you feel that you are going to need to use? In
    any case, typing in smtp and pop3 info into a news client is
    absolutely trivial.

    > If the resources used by the sendmail daemon are an issue: you can
    > start sendmail from inetd (don't do that on high mail-volume
    > systems).


    Why would you start sendmail from inetd on a single user dialup
    system? What would be the point?

    > Yes, it is certainly possible to send an receive mail without running
    > a MTA. But please don't bash people who do decide to run a MTA, even
    > if you think their needs are as basic as yours.


    Running an MTA on a single user dialup system is irresponsible and
    silly. System messages from remote servers, are all going to bounce
    because you are rarely online. This not only loads down the remote
    system sending you this stuff, because they have to keep trying to
    reach you, but you'll have no way of knowing if they have given up
    trying to reach you because you won't receive their messages unless
    you just happen to be logged in to the internet at the same time
    those messages are being sent out to you. Of course you can specify
    a proxy smarthost on a different server and fetch via pop3 these
    error messages but that kind of defeats the purpose, doesn't it?
    Your MTA would no longer be an MTA if you did that. In any case,
    the Bat Book is only 60 bucks (US) and we're sure you'll find all
    that you need to know quite quickly in its 1200 pages.

    On the other hand, if you are online all the time and especially if
    you have your own domain name, then having your own MTA gives you
    your own honest to goodness server and a good deal of freedom and
    that is great stuff.

    cordially, as always,

    rm

  15. Re: Slackware 11.0 dialup, mail, user groups

    wrote:

    > If he sends messages out and they bounce, then he is not going to
    > receive error messages unless he happens to be logged in at the
    > precise time those messages come to him.


    Bounces are sent to the envelope sender, not (necessarily) to the same
    machine that sent the original message. If the envelope sender is set
    correctly, the fact that his machine disconnects after sending queued
    messages has absolutely no effect on whether or not he'll receive
    bounces.

    > Oh, so you think it preferable that he never knows if his messages
    > go out or bounce or whatever?


    See above.

    > In a modern news client there are settings ...


    We're talking about mail delivery, not netnews.

    > ... if he is going to use sendmail, there is no reason for him to even
    > use fetchmail and a remote pop3 server. ...


    Perhaps you should learn what the purposes of each software is before
    making such ridiculous statements.

    > Why don't you tell him to setup his own domain name and then change
    > his dns servers each time his dialup dynamic ip address comes up ...
    > Of course he still won't get his error messages because sendmail
    > will only be up an hour a day, but who cares about that?


    I'm going to type this slowly, so perhaps you'll understand ...

    The error messages are sent to the envelope sender. As long as the
    domain-name portion of the envelope sender address has at least one MX
    system always reachable, there is absolutely no risk of losing any error
    messages. It has absolutely nothing (at all) to do with the machine
    that sent the original message.

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

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

  16. Re: Slackware 11.0 dialup, mail, user groups

    Sylvain Robitaille trolled:
    > wrote:


    We have tried to delete most of your sarcasm. You're not really as
    good at it as we are and to engage in such antics is beside the
    point and puts you at a decided disadvantage...

    >> If he sends messages out and they bounce, then he is not going to
    >> receive error messages unless he happens to be logged in at the
    >> precise time those messages come to him.


    > Bounces are sent to the envelope sender, not (necessarily) to the
    > same machine that sent the original message. If the envelope


    The default envelope sender is the sender of the original message.

    > sender is set correctly, the fact that his machine disconnects
    > after sending queued messages has absolutely no effect on whether
    > or not he'll receive bounces.


    Did you advise him to set a proxy? Or how to set one? No.

    > The error messages are sent to the envelope sender. As long as


    And where, in your message to Mike did you define the envelope
    sender as being anything other than his dialup account?

    > the domain-name portion of the envelope sender address has at
    > least one MX system always reachable, there is absolutely no risk
    > of losing any error messages.


    That's true. However, if the sender is, for example
    rm@justlinux.ca, to use our own, barely utilized, domain name, and
    our system is connected to the internet through dialup, then there
    is no MX available when we are offline.

    The default envelope sender will be rm@justlinux.ca and if that is a
    dialup, then we will miss bounces and likely other messages sent to
    us that we would receive if we were not a dialup. Perhaps you
    better explain to Mike how secondary MX boxes are setup. It just
    gets deeper and deeper with MTAs, doesn't it?

    On the other hand, if, in our example, we had an email address like
    xxx@rogers.com (and we do, although that's not it) then you would be
    right since rogers.com will always have a mail server going. But,
    any bounces sent to xxx@rogers.com will sit in a pop queue until we
    fetch it.

    So it depends on whether Mike is using his own domain or the one
    that his isp assigned to him. He hasn't told us this.

    If he uses his own domain limited to a dialup, with sendmail, he
    _will_ lose mail. If he uses an isp's domain name on his dialup,
    then he will be able to receive his bounces through pop or imap.
    But if that is the case, then there is no point in using sendmail
    because his client (or MUA) will send mail out to his isp's MTA,
    which is always up. (hopefully)

    > It has absolutely nothing (at all) to do with the machine that
    > sent the original message.


    Are you nuts? The machine that sent the original message is the
    default envelope sender.

    The only reason he would need fetchmail or sendmail is if he was
    using mutt or elm or some other dinosaur.

    cordially, as always,

    rm

  17. Re: Slackware 11.0 dialup, mail, user groups

    rm@biteme.org wrote:

    > Are you nuts? The machine that sent the original message is the
    > default envelope sender.


    The "envelope" in an SMTP transaction consists of an email address that
    defines the sender of the message, plus one or more email addresses
    that define the recipient(s). These are email addresses, not machines.
    The machine that sent the original message is acting as an MTA on
    behalf of the envelope sender, but is NOT itself "the envelope sender"
    (default or otherwise).

    If I send a message from "syl@alcor.concordia.ca" while connected to the
    net as (for example) "dialup-2.justlinux.ca", it simply doesn't matter
    at all that my system is on a dialup connection, nor does it matter
    whether or not my system hands the message to "smtp.justlinux.ca" for
    further relaying. Bounces will go to the envelope sender, which in this
    case (unless I've taken specific steps for it to be different) would be
    "syl@alcor.concordia.ca".

    If smtp.justlinux.ca is unable to deliver the message and needs to
    send a bounce, it will lookup the MX records for alcor.concordia.ca,
    and send the bounce to one of those systems, completely disregarding
    the fact that it accepted the message from dialup-2.justlinux.ca.

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

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

  18. Re: Slackware 11.0 dialup, mail, user groups

    Sylvain Robitaille trolled:
    > rm@biteme.org wrote:
    >
    >> Are you nuts? The machine that sent the original message is the
    >> default envelope sender.

    >
    > The "envelope" in an SMTP transaction consists of an email address
    > that defines the sender of the message, plus one or more email
    > addresses that define the recipient(s). These are email
    > addresses, not machines. The machine that sent the original
    > message is acting as an MTA on behalf of the envelope sender, but
    > is NOT itself "the envelope sender" (default or otherwise).


    Too much. Ok, the email address of the original machine is the
    default envelope sender. You are being pedantic.

    Oh, and BTW, the real issue is what is best for "Mike." Let's try
    not to lose focus.

    > If I send a message from "syl@alcor.concordia.ca" while connected to the
    > net as (for example) "dialup-2.justlinux.ca", it simply doesn't matter
    > at all that my system is on a dialup connection, nor does it matter
    > whether or not my system hands the message to "smtp.justlinux.ca" for
    > further relaying. Bounces will go to the envelope sender, which in this
    > case (unless I've taken specific steps for it to be different) would be
    > "syl@alcor.concordia.ca".


    And in our example the envelope sender would be xxx@justlinux.ca.
    Or more precisely xxx@realto.justlinux.ca.

    And since, we are using a single-user dialup system, like "Mike"
    all things justlinux.ca refers to only one machine in this universe.
    The bounces will go to the envelope sender which in our case, is
    xxx@realto.justlinux.ca. And there is only one machine in the world
    that is associated with that address and that machine's ip address
    is defined in our dns servers which are updated each time our
    dynamic ip address changes.

    > If smtp.justlinux.ca is unable to deliver the message and needs to
    > send a bounce, it will lookup the MX records for alcor.concordia.ca,
    > and send the bounce to one of those systems, completely disregarding
    > the fact that it accepted the message from dialup-2.justlinux.ca.


    But xxx@realto.justlinux.ca is sending the original message to you,
    and if smtp.concordia.ca has to send a bounce, it will lookup up the
    MX record for domain justlinux.ca, the envelope sender, and send the
    bounce to that system.

    Except that domain name isn't up because it is attached to an
    intermittent dialup machine. And since we are really small-time
    (like "Mike") we don't have a secondary MX defined. So where does
    the bounce go now? smtp.concordia.ca will attempt to send out the
    bounce to realto.justlinux.ca a certain number of tries, over a
    small period of time (that the concordia admin has specified) before
    it either reaches the dialup while logged in or it gives up.

    And when it gives up, the bounce is lost.

    If Mike is using his isp's domain, then what you are saying is
    correct. But if Mike is using his own domain name and he has not
    changed the envelope sender address then you are wrong. Mike hasn't
    told us whose domain he is using. And you haven't told him how to
    change his envelope sender address.

    In any case, specifying smtp.server.com and pop3.server.com in his
    mail client's appropriate fields makes this whole discussion moot
    and is far and away the easiest solution to his original problem of
    making sure that he is sending out all of his emails before he logs
    out.

    cordially, as always,

    rm

  19. Re: Slackware 11.0 dialup, mail, user groups

    rm@realto.justlinux.ca wrote:
    > Kees Theunissen wrote:
    >
    >>Franklin wrote:
    >>
    >>>I have not seen anything the OP stated that would make me believe
    >>>sendmail was a requirement for his needs or that any basic mail client
    >>>functionality was less than what he required.
    >>>
    >>>In other words, until I see any info to the contrary, I agree with rm.

    >>
    >>As far as I remember the OP didn't mention his needs or any reason
    >>why he decided to run sendmail. That would explain why you didn't see
    >>it; it was not the subject of this discussion.
    >>
    >>I agree that it is possible to have basic mail functionality (sending
    >>and receiving messages) without running sendmail or any other MTA, if
    >>your mail client has smtp-functionality to submit messages. But there
    >>still are valid reasons to run a local MTA.

    >
    >
    > Not on a dialup system. Only on a server.


    Even on a dialup system.
    >
    >
    >>I prefer to run sendmail on all my systems (workstation at home,
    >>workstations and servers at work) for the following reasons:
    >>-- I need a MTA if I want to see (error-)output from cron-jobs.
    >> This was already mentioned by Sylvain.

    >
    >
    > What cron jobs are you running on a dialup system? In any case, you
    > can check logs for those records.


    Examples of cronjobs running on a dialup system:
    -- Logrotate and perhaps other cleanup progs. Not every cronjob is
    related to network connectivity
    -- Perhaps dial out a few times per day to fetch new mail and
    transmit queued messages. :-)
    >
    >
    >>-- It allows me to easily send mail from scripts using the 'mail'
    >> command.

    >
    >
    > Easily? What is easy about sending email from scripts using the
    > mail command?


    Something like:

    echo "It realy is easy!" | \
    mail -s "Scripting mail submission." rm@realto.justlinux.ca

    Which part don't you understand?


    >
    >
    >>-- It allows me to directly deliver mail to other users of the
    >> system, without sending it to the ISP's mail server and fetching
    >> it again.

    >
    >
    > Well, if that's the case, then you are using a server, so go ahead
    > and knock yourself out with sendmail.


    No I'm talking about several user acounts on the same system.
    That might be a home computer shared by the whole family.

    >
    > But the OP is talking about a single-user, dialup system, and none
    > of the reasons you want sendmail running apply to his system.
    >


    The OP asked how he could start a queue run. Where did he tell
    that it was a single-user system?

    >
    >>-- All outbound mail will pass sendmail (unless I configure a MUA
    >> to send directly to the ISP) so sendmail supplies a single
    >> configuration point.

    >
    >
    > And since the OP is a single user, he is already a single
    > configuration point. In any case, instead of setting up individual
    > users within a client, you are now stuck with setting up individual
    > users with sendmail which isn't all that easy unless you are
    > strictly local.
    >


    I choose to do in in sendmail. Once sendmail is properly
    configured _all_ MUA's will "just work" for all users without
    further configuration.

    >
    >>I only have to configure a smarthost and
    >>the translation from login_name@local.host.name to user@ips.domain
    >>in sendmail and it will apply to whatever MUA I chose without
    >>further configuration.

    >
    >
    > And how many MUAs do you feel that you are going to need to use? In
    > any case, typing in smtp and pop3 info into a news client is
    > absolutely trivial.
    >


    This is not about how many MUA's I'm going to need to use. Some
    systems are multi-user. Sometimes I'm "only" root, not even a user
    of the system. I don't know -and don't care- how many MUA's the
    (other) users want to use or which one they are using.
    If sendmail is properly configured _all_ MUA's "just work" without
    further configuration.

    >
    >>If the resources used by the sendmail daemon are an issue: you can
    >>start sendmail from inetd (don't do that on high mail-volume
    >>systems).

    >
    >
    > Why would you start sendmail from inetd on a single user dialup
    > system? What would be the point?
    >


    You'll gain all benefits mentioned above without permanently using
    the memory needed by the sendmail daemon. That could be an advantage
    on a low-end system.

    >
    >>Yes, it is certainly possible to send an receive mail without running
    >>a MTA. But please don't bash people who do decide to run a MTA, even
    >>if you think their needs are as basic as yours.

    >
    >
    > Running an MTA on a single user dialup system is irresponsible and
    > silly. System messages from remote servers, are all going to bounce
    > because you are rarely online. This not only loads down the remote
    > system sending you this stuff, because they have to keep trying to
    > reach you, but you'll have no way of knowing if they have given up
    > trying to reach you because you won't receive their messages unless
    > you just happen to be logged in to the internet at the same time
    > those messages are being sent out to you. Of course you can specify
    > a proxy smarthost on a different server and fetch via pop3 these
    > error messages but that kind of defeats the purpose, doesn't it?


    Should I explain the difference between using sendmail just to queue
    and transmit messages (that is running as a smtp-client for outbound
    messages) and running sendmail as a smtp server (daemon) to
    directly receive inbound messages from the internet?
    Doing the second would be irresponsible with a dialup connection,
    yes - even stupid.
    Do I realy have to explain that difference?


    > Your MTA would no longer be an MTA if you did that. In any case,
    > the Bat Book is only 60 bucks (US) and we're sure you'll find all
    > that you need to know quite quickly in its 1200 pages.
    >

    You don't have to start with the Bat Book.
    In most cases /usr/share/sendmail/cf/README will be sufficient
    and there is /usr/doc/sendmail-/op/op.* for the details
    :-)

    > On the other hand, if you are online all the time and especially if
    > you have your own domain name, then having your own MTA gives you
    > your own honest to goodness server and a good deal of freedom and
    > that is great stuff.
    >


    A properly configured sendmail can also be usefull on a dialup
    system. You don't _have_ to do that but you _can_ do, and there
    might be good reasons to do so.
    And what's against doing it just for the fun of being able
    to manage sendmail?

    > cordially, as always,
    >
    > rm


    Regards,

    Kees.

    --
    Kees Theunissen.

  20. Re: Slackware 11.0 dialup, mail, user groups

    Kees Theunissen trolled:

    >>>I agree that it is possible to have basic mail functionality (sending
    >>>and receiving messages) without running sendmail or any other MTA, if
    >>>your mail client has smtp-functionality to submit messages. But there
    >>>still are valid reasons to run a local MTA.

    >>
    >>
    >> Not on a dialup system. Only on a server.

    >
    > Even on a dialup system.


    Nope.

    >> What cron jobs are you running on a dialup system? In any case, you
    >> can check logs for those records.


    > Examples of cronjobs running on a dialup system:
    > -- Logrotate and perhaps other cleanup progs. Not every cronjob is
    > related to network connectivity


    About 4:40 am.

    > -- Perhaps dial out a few times per day to fetch new mail and
    > transmit queued messages. :-)


    If you check another post you will see that we corrected ourself
    about the crond and atd. Obviously these have to be going, whether
    you are online or not.

    >>>-- It allows me to easily send mail from scripts using the 'mail'
    >>> command.


    >> Easily? What is easy about sending email from scripts using the
    >> mail command?


    > Something like:
    >
    > echo "It realy is easy!" | \
    > mail -s "Scripting mail submission." rm@realto.justlinux.ca


    Go ahead and send it.

    > Which part don't you understand?


    It's easy to understand for someone who knows elementary bash. But
    it is still far more difficult than simply clicking on a thunderbird
    or kwrite button.

    And which part of this don't you understand?

    >>>-- It allows me to directly deliver mail to other users of the
    >>> system, without sending it to the ISP's mail server and fetching
    >>> it again.


    >> Well, if that's the case, then you are using a server, so go ahead
    >> and knock yourself out with sendmail.


    > No I'm talking about several user acounts on the same system.
    > That might be a home computer shared by the whole family.


    You'll find, in the real world, that most people now use yahoo or
    hotmail so they can easily access their emails at work or school.
    Only hopelessly pathetic little geeks sit around and create mail
    systems for the whole family. And no doubt you complain when nobody
    uses it, right?

    >> But the OP is talking about a single-user, dialup system, and none
    >> of the reasons you want sendmail running apply to his system.


    > The OP asked how he could start a queue run. Where did he tell
    > that it was a single-user system?


    Queue run? We didn't see anything about any queues in his posting.
    But what we did see, ss that all he cares about is "Mike's" mail
    being sent out. Do you think he has more than one user named Mike
    on his system?

    >> And since the OP is a single user, he is already a single
    >> configuration point. In any case, instead of setting up
    >> individual users within a client, you are now stuck with setting
    >> up individual users with sendmail which isn't all that easy
    >> unless you are strictly local.


    > I choose to do in in sendmail. Once sendmail is properly
    > configured _all_ MUA's will "just work" for all users without
    > further configuration.


    Great. Build your ship in a bottle. But don't expect that ship to
    haul any freight.

    cordially, as always,

    rm

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