Limitation on the number of subscribers to a MajorMajor mailing list/ - OS2

This is a discussion on Limitation on the number of subscribers to a MajorMajor mailing list/ - OS2 ; On 9 Jan 2007 20:07:53 GMT, Bob Eager wrote: > He can always block port 25 on his router, and they'll never see it. True. There's a way around most anything. Some might object to this on the grounds that ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 39 of 39

Thread: Limitation on the number of subscribers to a MajorMajor mailing list/

  1. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On 9 Jan 2007 20:07:53 GMT, Bob Eager wrote:

    > He can always block port 25 on his router, and they'll never see it.


    True. There's a way around most anything. Some might object to this on
    the grounds that violating an agreement is simply not something one
    should do. In Stan's case, though, I'm inclined toward the idea that the
    agreement has already been violated by the ISP and, therefore, no longer
    actually exists.

    --
    The "mypacks.net" address from which this message was sent is
    legitimate and not spam-trapped. It is, however, disposable.

  2. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Tue, 9 Jan 2007 20:14:08 UTC, Michael DeBusk
    wrote:

    > On 9 Jan 2007 20:07:53 GMT, Bob Eager wrote:
    >
    > > He can always block port 25 on his router, and they'll never see it.

    >
    > True. There's a way around most anything. Some might object to this on
    > the grounds that violating an agreement is simply not something one
    > should do. In Stan's case, though, I'm inclined toward the idea that the
    > agreement has already been violated by the ISP and, therefore, no longer
    > actually exists.


    It's also arguable (says he, being devil's advocate and no more) that he
    isn't running an Internet server because it can't be seen from the
    Internet if the firewall stealths that port!

    Makes me realise how lucky I am to have an ISP that lets me run anything
    I want, on any ports, AND gives me a large block of static IPs!



  3. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Tue, 9 Jan 2007 19:46:34 UTC, Michael DeBusk
    opined:
    > On 09 Jan 2007 14:53:36 GMT, Stan Goodman wrote:
    >
    > > Thanks, but I don't want ads at the bottom of anything, certainly if
    > > I have no control over what they are advertising for.

    >
    > I tend to count on the fact that most people ignore ads anyway.
    >
    > > I'm going to try Bob's suggestion, which sounds about as close to
    > > ideal as one could hope for, barring the elimination of the stupid
    > > limitation.

    >
    > It does sound like a good plan, as long as your ISP has no problem with
    > you running a server on your machine while hooked to them. (It violates
    > the ToS with some ISPs.)
    >

    I'll worry about that when it happens.


  4. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Tue, 9 Jan 2007 20:23:50 UTC, "Bob Eager" opined:
    > On Tue, 9 Jan 2007 20:14:08 UTC, Michael DeBusk
    > wrote:
    >
    > > On 9 Jan 2007 20:07:53 GMT, Bob Eager wrote:
    > >
    > > > He can always block port 25 on his router, and they'll never see it.


    FWIW, I have it set up for port 24, as per suggestion in the SMTP docs, just
    to keep it separate from other mail.

    > > True. There's a way around most anything. Some might object to this on
    > > the grounds that violating an agreement is simply not something one
    > > should do. In Stan's case, though, I'm inclined toward the idea that the
    > > agreement has already been violated by the ISP and, therefore, no longer
    > > actually exists.

    >
    > It's also arguable (says he, being devil's advocate and no more) that he
    > isn't running an Internet server because it can't be seen from the
    > Internet if the firewall stealths that port!


    If you do something that can't be detected, essentially you haven't done it
    (viz Gilbert & Sullivan, "The Mikado", relative to a discussion of whether,
    after you have told the authorities you have done something, you need to
    actually do it at all). Detectability is all.

    > Makes me realise how lucky I am to have an ISP that lets me run anything
    > I want, on any ports, AND gives me a large block of static IPs!


    This must cost a fortune.

    My ISP charges significantly for one static IP; the account on the hosting
    service has one static IP.


  5. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Tue, 9 Jan 2007 23:51:57 UTC, "Stan Goodman"
    wrote:

    > On Tue, 9 Jan 2007 20:23:50 UTC, "Bob Eager" opined:
    > > On Tue, 9 Jan 2007 20:14:08 UTC, Michael DeBusk
    > > wrote:
    > >
    > > > On 9 Jan 2007 20:07:53 GMT, Bob Eager wrote:
    > > >
    > > > > He can always block port 25 on his router, and they'll never see it.

    >
    > FWIW, I have it set up for port 24, as per suggestion in the SMTP docs, just
    > to keep it separate from other mail.


    Yes, that's quite useful; I use it here (and originally implemented it)
    to provide a way of filtering the kids' mail.

    > > Makes me realise how lucky I am to have an ISP that lets me run anything
    > > I want, on any ports, AND gives me a large block of static IPs!

    >
    > This must cost a fortune.
    >
    > My ISP charges significantly for one static IP; the account on the hosting
    > service has one static IP.


    No, I said 'gives' (OK, nothing is free). But they charge me about $50 a
    month for service. That may seem expensive, but...

    There's a cap of 3GB/month which applies only to downloads, and only
    during working hours Monday-Friday; at all other times, and for all
    uploads too, there is no limit. I get 1GB of webspace and an included
    co.uk domain name. DNS and secondary included for that domain, also
    mail servers incoming and outgoing. It also includes secondary DNS and
    secondary MX, and outgoing mail server, for any other domains I have
    registered through them. No limits, throttling, shaping, port blocking,
    or transparent proxies. I have a block of 32 IPs and another block of 8.
    No charge for these over and above the basic charge. If I wanted more I
    could have them and pay no more. And I can run mail, web, FTP and indeed
    any other kind of server as well.

    Oh, I can have a block of IPv6 addresses too, and have them routed.

    Best of all is the support. Nominally working hours only, but in
    practice better than that. If I call, I get a receptionist who will put
    me through to a real techie who does not use a script, merely his own
    knowledge (which is plenty). Email support is good, too. I once emailed
    a request for a new domain registration on a Friday at 5.20 p.m. By 5.35
    it was registered, DNS was in place and I could use it.

  6. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Tue, 09 Jan 2007 20:14:08 GMT, Michael DeBusk
    wrote:

    > On 9 Jan 2007 20:07:53 GMT, Bob Eager wrote:
    >
    >> He can always block port 25 on his router, and they'll never see it.

    >
    > True. There's a way around most anything. Some might object to this on
    > the grounds that violating an agreement is simply not something one
    > should do. In Stan's case, though, I'm inclined toward the idea that the
    > agreement has already been violated by the ISP and, therefore, no longer
    > actually exists.


    What bloody business is it of the ISP in any case? What you do with your
    connection is up to you. It makes sod all difference whether you are
    running a 'server' application or a 'client' application. I cannot imagine
    what problems there would be with this, apart from the clueless letting
    themselves be used as a spam relay if running a mail server.

    Technically, something as simple as an ordinary FTP client can act as a
    'server' (i.e. receive an incoming connection) as part of its normal
    operation.

  7. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 00:47:21 UTC in comp.os.os2.apps, Paul Ratcliffe
    wrote:

    >
    > What bloody business is it of the ISP in any case? What you do with your
    > connection is up to you. It makes sod all difference whether you are
    > running a 'server' application or a 'client' application. I cannot imagine
    > what problems there would be with this, apart from the clueless letting
    > themselves be used as a spam relay if running a mail server.


    That *is* the problem, too many completely clueless people who know nothing
    about computers. Even those that are meant to be knowledgeable often aren't and
    ADSL connections are marketed as consumer items to people that can barely turn a
    PC on, let alone solve a problem with one.

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

  8. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On 9 Jan 2007 20:23:50 GMT, Bob Eager wrote:

    > It's also arguable (says he, being devil's advocate and no more) that
    > he isn't running an Internet server because it can't be seen from the
    > Internet if the firewall stealths that port!


    An excellent point! It's really only a server as far as the docs are
    concerned; he's using it as an MTA.

    --
    The "mypacks.net" address from which this message was sent is
    legitimate and not spam-trapped. It is, however, disposable.

  9. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 00:47:21 GMT, Paul Ratcliffe
    wrote:

    > What bloody business is it of the ISP in any case?


    You'll get no argument from me there. My point is that, sometimes, they
    insist on making it their business, whether they should do so or not.

    --
    The "mypacks.net" address from which this message was sent is
    legitimate and not spam-trapped. It is, however, disposable.

  10. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Mon, 8 Jan 2007 20:24:55 UTC, "Bob Eager" opined:
    > On Mon, 8 Jan 2007 19:57:15 UTC, "Stan Goodman"
    > wrote:
    >
    > > > Is there a reasonable way for you to cut your address list into four parts?

    > >
    > > I have received an interesting reply from the hosting service. They suggest
    > > that I write a php script that would avoid the restriction by sending all
    > > copies of messages to all ~100 subscribers one at a time. In my naivete,
    > > that's what I thought MajorMajor was using, but apparently they mean to
    > > initiate entirely seperate SEND operations for each addressee.

    >
    > I can suggest a solution, I think. This uses my lightweight mail server
    > and client. It involves a small REXX script.
    >
    > Set up my lightweight mail server on your machine (takes less than 10
    > minutes). Get MajorMajor to send all of its mail to that. All the server
    > does is store it.
    >
    > Have a REXX script that executes (say) every five minutes. It enumerates
    > the files in the send directory, and picks a number [1] of names. It
    > feeds that to my lightweight SMTP client (just a short command) which
    > then sends those files in a single SMTP session.
    >
    > [1] number chosen at will, but obviously less than 25.


    I've installed SMTPd and the client, and written a draft of a REXX script to
    transfer files in groups from the output directory of SMTPd to the input
    directory of the client, and to distribute the files. I think the two
    programs are properly installed now, and the next orderly step is to see
    exactly what SMTPd's output files look like.

    For this purpose, I changed only one entry in the notebook of the MajorMajor
    Configuration program: on the Basic page, the field for [SMTP server for
    outgoing mail] -> [Hostname] to contain the IP address of the machine that
    all the programs are on. I also unchecked the [Authorization] box of course.
    I made no other changes.

    I sent a message to one of my mailing lists in the way I usually do (to its
    mailbox on the server of the hosting service), and let MajorMajor retrieve
    it for "distribution". I expected the product of SMTPd to be deposited in
    its output directory, which is specified in CONFIG.SYS.

    What actually happened was that MajorMajor reported that it could not reach
    the SMTP server. Why? What didn't I do?


  11. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 21:39:55 UTC, "Stan Goodman"
    wrote:

    > > Set up my lightweight mail server on your machine (takes less than 10
    > > minutes). Get MajorMajor to send all of its mail to that. All the server
    > > does is store it.
    > >
    > > Have a REXX script that executes (say) every five minutes. It enumerates
    > > the files in the send directory, and picks a number [1] of names. It
    > > feeds that to my lightweight SMTP client (just a short command) which
    > > then sends those files in a single SMTP session.
    > >
    > > [1] number chosen at will, but obviously less than 25.

    >
    > I've installed SMTPd and the client, and written a draft of a REXX script to
    > transfer files in groups from the output directory of SMTPd to the input
    > directory of the client, and to distribute the files.


    You don't really need to do that. SMTPD just collects the files in one
    directory.

    The REXX script calls SysFileTree or similar, and gets N filenames. It
    then invokes SMTP (the client) with that list of names as a parameter.
    SMTP just sends all of those files to the ISP. No need for any file
    handling at all.

    > I think the two
    > programs are properly installed now, and the next orderly step is to see
    > exactly what SMTPd's output files look like.


    Absolutely no need. You never need to touch them.

    > For this purpose, I changed only one entry in the notebook of the MajorMajor
    > Configuration program: on the Basic page, the field for [SMTP server for
    > outgoing mail] -> [Hostname] to contain the IP address of the machine that
    > all the programs are on. I also unchecked the [Authorization] box of course.
    > I made no other changes.
    >
    > I sent a message to one of my mailing lists in the way I usually do (to its
    > mailbox on the server of the hosting service), and let MajorMajor retrieve
    > it for "distribution". I expected the product of SMTPd to be deposited in
    > its output directory, which is specified in CONFIG.SYS.
    >
    > What actually happened was that MajorMajor reported that it could not reach
    > the SMTP server. Why? What didn't I do?


    Have a look at the INETD window on the machine that has the SMTP server.
    Either INETD wasn't running, or it couldn't invoke SMTPD. Or it's
    listening on the wrong port.

    Oh...and I assume that you have set up MajorMajor to send to port 25. If
    not, changes to INETD.LST are needed as specified in the SMTPD README.



  12. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 21:41:21 UTC, "Bob Eager" opined:
    > On Wed, 10 Jan 2007 21:39:55 UTC, "Stan Goodman"
    > wrote:
    >
    > > > Set up my lightweight mail server on your machine (takes less than 10
    > > > minutes). Get MajorMajor to send all of its mail to that. All the server
    > > > does is store it.
    > > >
    > > > Have a REXX script that executes (say) every five minutes. It enumerates
    > > > the files in the send directory, and picks a number [1] of names. It
    > > > feeds that to my lightweight SMTP client (just a short command) which
    > > > then sends those files in a single SMTP session.
    > > >
    > > > [1] number chosen at will, but obviously less than 25.

    > >
    > > I've installed SMTPd and the client, and written a draft of a REXX script to
    > > transfer files in groups from the output directory of SMTPd to the input
    > > directory of the client, and to distribute the files.

    >
    > You don't really need to do that. SMTPD just collects the files in one
    > directory.


    Yes, but I want to send them out in groups of, say, twenty. The way the
    script is written is that it moves twenty at a time from where SMTPd put
    them to another directory where I can tell SMTP to send everything that is
    there. It may be that, when I see exactly what SMTPd gives me, I'll
    perceive that there is a better way to do this -- or that I am doing
    something unnecessarly. At the moment, however, I just want to see the
    product of SMTPd in its output directory.

    > The REXX script calls SysFileTree or similar, and gets N filenames. It
    > then invokes SMTP (the client) with that list of names as a parameter.
    > SMTP just sends all of those files to the ISP. No need for any file
    > handling at all.
    >
    > > I think the two
    > > programs are properly installed now, and the next orderly step is to see
    > > exactly what SMTPd's output files look like.

    >
    > Absolutely no need. You never need to touch them.


    How to divide them into groups of =<25?

    > > For this purpose, I changed only one entry in the notebook of the MajorMajor
    > > Configuration program: on the Basic page, the field for [SMTP server for
    > > outgoing mail] -> [Hostname] to contain the IP address of the machine that
    > > all the programs are on. I also unchecked the [Authorization] box of course.
    > > I made no other changes.
    > >
    > > I sent a message to one of my mailing lists in the way I usually do (to its
    > > mailbox on the server of the hosting service), and let MajorMajor retrieve
    > > it for "distribution". I expected the product of SMTPd to be deposited in
    > > its output directory, which is specified in CONFIG.SYS.
    > >
    > > What actually happened was that MajorMajor reported that it could not reach
    > > the SMTP server. Why? What didn't I do?

    >
    > Have a look at the INETD window on the machine that has the SMTP server.
    > Either INETD wasn't running, or it couldn't invoke SMTPD. Or it's
    > listening on the wrong port.


    Everything is on one machine. I assume INETD is running, because its window
    comes up with its one line when the machine boots.

    > Oh...and I assume that you have set up MajorMajor to send to port 25. If
    > not, changes to INETD.LST are needed as specified in the SMTPD README.


    Port 25 is MajorMajor's default, and that's what it always has been. Now I
    am changing it to port 24 according to the instructions in the readme.

    I have put "smtph" before both "24" lines of SERVICES. I have added "smtph
    tcp smtpd" to INETD.LST (though I don't see why it needs the original line
    anymore). The new line in CONFIG.SYS should be SET SMTPH=24, is that
    correct?

    But the failure happened before I made any of these changes.




  13. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 23:00:33 UTC, "Stan Goodman"
    wrote:

    > > > I've installed SMTPd and the client, and written a draft of a REXX script to
    > > > transfer files in groups from the output directory of SMTPd to the input
    > > > directory of the client, and to distribute the files.

    > >
    > > You don't really need to do that. SMTPD just collects the files in one
    > > directory.

    >
    > Yes, but I want to send them out in groups of, say, twenty. The way the
    > script is written is that it moves twenty at a time from where SMTPd put
    > them to another directory where I can tell SMTP to send everything that is
    > there.


    They're just files. You can send them from where they are.

    The REXX script works like this (in English, not real REXX):

    do forever /* loop at intervals of (say) 5 minutes */
    do forever /* loop until directory is empty */
    call sysfiletree to get list of all filenames in smtpd directory,
    say into f.
    if f.0 = 0 then leave /* nothing left */
    if f.0 > 20 then n = 20 else n = f.0 /* get max of 20 */
    s = ''
    do i = 1 to n
    s = s f.i /* add filename to list */
    end
    /* now have s containing up to 20 filenames */
    'smtp -sserver' s /* call smtp to send files in s*/
    end
    sleep for some interval
    end

    > It may be that, when I see exactly what SMTPd gives me, I'll
    > perceive that there is a better way to do this -- or that I am doing
    > something unnecessarly. At the moment, however, I just want to see the
    > product of SMTPd in its output directory.


    > How to divide them into groups of =<25?


    See above. Note that SMTPD takes one or more filenames (each a message)
    as parameter. It can do a whole directory, but that isn't needed here.
    The files don't have to move.

    > > > For this purpose, I changed only one entry in the notebook of the MajorMajor
    > > > Configuration program: on the Basic page, the field for [SMTP server for
    > > > outgoing mail] -> [Hostname] to contain the IP address of the machine that
    > > > all the programs are on. I also unchecked the [Authorization] box of course.
    > > > I made no other changes.


    OK.

    > > > I sent a message to one of my mailing lists in the way I usually do (to its
    > > > mailbox on the server of the hosting service), and let MajorMajor retrieve
    > > > it for "distribution". I expected the product of SMTPd to be deposited in
    > > > its output directory, which is specified in CONFIG.SYS.
    > > >
    > > > What actually happened was that MajorMajor reported that it could not reach
    > > > the SMTP server. Why? What didn't I do?

    > >
    > > Have a look at the INETD window on the machine that has the SMTP server.
    > > Either INETD wasn't running, or it couldn't invoke SMTPD. Or it's
    > > listening on the wrong port.

    >
    > Everything is on one machine. I assume INETD is running, because its window
    > comes up with its one line when the machine boots.


    Yes, but what's in that window after MajorMajor tries to contact SMTPD?
    It should show INETD spawnning (sic) the SMTPD process.

    Also check \mptn\etc\smtpd.log to see what it says.

    > > Oh...and I assume that you have set up MajorMajor to send to port 25. If
    > > not, changes to INETD.LST are needed as specified in the SMTPD README.

    >
    > Port 25 is MajorMajor's default, and that's what it always has been. Now I
    > am changing it to port 24 according to the instructions in the readme.
    >
    > I have put "smtph" before both "24" lines of SERVICES. I have added "smtph
    > tcp smtpd" to INETD.LST (though I don't see why it needs the original line
    > anymore).


    The original line is necessary only if you want to listen on 25 too.

    > The new line in CONFIG.SYS should be SET SMTPH=24, is that
    > correct?


    No, the SET SMTPH specifies the directory where files are stored after
    receipt by SMTPD.
    (same as for SET SMTP).

    > But the failure happened before I made any of these changes.


    What is the SET SMTP line? If it isn't a valid directory name, it won't
    work. Error messages may appear in the INETD window, or in SMTPD.LOG.




  14. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 21:41:21 UTC, "Bob Eager" opined:
    > On Wed, 10 Jan 2007 21:39:55 UTC, "Stan Goodman"
    > wrote:
    >
    > > > Set up my lightweight mail server on your machine (takes less than 10
    > > > minutes). Get MajorMajor to send all of its mail to that. All the server
    > > > does is store it.
    > > >
    > > > Have a REXX script that executes (say) every five minutes. It enumerates
    > > > the files in the send directory, and picks a number [1] of names. It
    > > > feeds that to my lightweight SMTP client (just a short command) which
    > > > then sends those files in a single SMTP session.
    > > >
    > > > [1] number chosen at will, but obviously less than 25.

    > >
    > > I've installed SMTPd and the client, and written a draft of a REXX script to
    > > transfer files in groups from the output directory of SMTPd to the input
    > > directory of the client, and to distribute the files.

    >
    > You don't really need to do that. SMTPD just collects the files in one
    > directory.
    >
    > The REXX script calls SysFileTree or similar, and gets N filenames. It
    > then invokes SMTP (the client) with that list of names as a parameter.
    > SMTP just sends all of those files to the ISP. No need for any file
    > handling at all.
    >
    > > I think the two
    > > programs are properly installed now, and the next orderly step is to see
    > > exactly what SMTPd's output files look like.

    >
    > Absolutely no need. You never need to touch them.
    >
    > > For this purpose, I changed only one entry in the notebook of the MajorMajor
    > > Configuration program: on the Basic page, the field for [SMTP server for
    > > outgoing mail] -> [Hostname] to contain the IP address of the machine that
    > > all the programs are on. I also unchecked the [Authorization] box of course.
    > > I made no other changes.
    > >
    > > I sent a message to one of my mailing lists in the way I usually do (to its
    > > mailbox on the server of the hosting service), and let MajorMajor retrieve
    > > it for "distribution". I expected the product of SMTPd to be deposited in
    > > its output directory, which is specified in CONFIG.SYS.
    > >
    > > What actually happened was that MajorMajor reported that it could not reach
    > > the SMTP server. Why? What didn't I do?

    >
    > Have a look at the INETD window on the machine that has the SMTP server.
    > Either INETD wasn't running, or it couldn't invoke SMTPD. Or it's
    > listening on the wrong port.
    >
    > Oh...and I assume that you have set up MajorMajor to send to port 25. If
    > not, changes to INETD.LST are needed as specified in the SMTPD README.


    I've rebooted. As far as I can see, all the port settings are correct (24 in
    MajorMajor and in SERVICES; "smtph tcp smtpd" added in INETD.LST). INETD.EXE
    is in the task list, so it is running. I sent a message to the list's
    mailbox, and watched MajorMajor try to handle it; the result was as before:

    Processing one item
    Could not connect to SMTP host
    ϯ/
    Message from sent to 0 recipients (0 failures)

    For what it's worth, the three characters in the third line are: an
    intersection of a horizontal double line and a vertical single line;
    epsilon; slash (in case they look different on your screen).

    If it means anything, Shields-Up shows port 25 as open, although the daemon
    is on port 24.

    It's now 0140 here, and I'm going to turn in.

    --
    Stan Goodman


  15. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 23:41:41 UTC, "Bob Eager" wrote:

    > do forever /* loop at intervals of (say) 5 minutes */
    > do forever /* loop until directory is empty */
    > call sysfiletree to get list of all filenames in smtpd directory,
    > say into f.
    > if f.0 = 0 then leave /* nothing left */
    > if f.0 > 20 then n = 20 else n = f.0 /* get max of 20 */
    > s = ''
    > do i = 1 to n
    > s = s f.i /* add filename to list */
    > end
    > /* now have s containing up to 20 filenames */
    > 'smtp -sserver' s /* call smtp to send files in s*/
    > end
    > sleep for some interval
    > end


    I should have said that this solution has a minor limitation. Total
    length of filenames and command must not exceed 1024 (max length of
    command line). Each filename plus its leading space is 15 characters, so
    20 of them uses 300 bytes. Limiting the total length to 900 bytes means
    that the rest of the filename (leading directory name) should not be
    more than 30 characters in length. Unlikely to be a problem but I
    mention it in case.

    Of course, the REXX script can set the directory to be the default to
    start with, by using:

    call directory value('SMTP',,'OS2ENVIRONMENT')

    then:

    f.i = filespec("name", f.i) to strip off the leading directory
    name before concatenating into s.

    and then the limit is about 68 messages per loop.


  16. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 23:41:41 UTC, "Bob Eager" opined:
    > On Wed, 10 Jan 2007 23:00:33 UTC, "Stan Goodman"
    > wrote:
    >
    > > > > I've installed SMTPd and the client, and written a draft of a REXX script to
    > > > > transfer files in groups from the output directory of SMTPd to the input
    > > > > directory of the client, and to distribute the files.
    > > >
    > > > You don't really need to do that. SMTPD just collects the files in one
    > > > directory.

    > >
    > > Yes, but I want to send them out in groups of, say, twenty. The way the
    > > script is written is that it moves twenty at a time from where SMTPd put
    > > them to another directory where I can tell SMTP to send everything that is
    > > there.

    >
    > They're just files. You can send them from where they are.
    >
    > The REXX script works like this (in English, not real REXX):
    >
    > do forever /* loop at intervals of (say) 5 minutes */
    > do forever /* loop until directory is empty */
    > call sysfiletree to get list of all filenames in smtpd directory,
    > say into f.
    > if f.0 = 0 then leave /* nothing left */
    > if f.0 > 20 then n = 20 else n = f.0 /* get max of 20 */
    > s = ''
    > do i = 1 to n
    > s = s f.i /* add filename to list */
    > end
    > /* now have s containing up to 20 filenames */
    > 'smtp -sserver' s /* call smtp to send files in s*/
    > end
    > sleep for some interval
    > end
    >
    > > It may be that, when I see exactly what SMTPd gives me, I'll
    > > perceive that there is a better way to do this -- or that I am doing
    > > something unnecessarly. At the moment, however, I just want to see the
    > > product of SMTPd in its output directory.

    >
    > > How to divide them into groups of =<25?

    >
    > See above. Note that SMTPD takes one or more filenames (each a message)
    > as parameter. It can do a whole directory, but that isn't needed here.
    > The files don't have to move.


    Now I know. From reading the readme file, which shows only how to send all
    the files in the directory, I didn't guess the way you have done. Other than
    substituting your list for my moving to a separate directory, my script is
    virtually identical with yours.

    > > > > For this purpose, I changed only one entry in the notebook of the MajorMajor
    > > > > Configuration program: on the Basic page, the field for [SMTP server for
    > > > > outgoing mail] -> [Hostname] to contain the IP address of the machine that
    > > > > all the programs are on. I also unchecked the [Authorization] box of course.
    > > > > I made no other changes.

    >
    > OK.
    >
    > > > > I sent a message to one of my mailing lists in the way I usually do (to its
    > > > > mailbox on the server of the hosting service), and let MajorMajor retrieve
    > > > > it for "distribution". I expected the product of SMTPd to be deposited in
    > > > > its output directory, which is specified in CONFIG.SYS.
    > > > >
    > > > > What actually happened was that MajorMajor reported that it could not reach
    > > > > the SMTP server. Why? What didn't I do?
    > > >
    > > > Have a look at the INETD window on the machine that has the SMTP server.
    > > > Either INETD wasn't running, or it couldn't invoke SMTPD. Or it's
    > > > listening on the wrong port.

    > >
    > > Everything is on one machine. I assume INETD is running, because its window
    > > comes up with its one line when the machine boots.

    >
    > Yes, but what's in that window after MajorMajor tries to contact SMTPD?
    > It should show INETD spawnning (sic) the SMTPD process.


    Sic? SpawNNing?

    > Also check \mptn\etc\smtpd.log to see what it says.
    >
    > > > Oh...and I assume that you have set up MajorMajor to send to port 25. If
    > > > not, changes to INETD.LST are needed as specified in the SMTPD README.

    > >
    > > Port 25 is MajorMajor's default, and that's what it always has been. Now I
    > > am changing it to port 24 according to the instructions in the readme.
    > >
    > > I have put "smtph" before both "24" lines of SERVICES. I have added "smtph
    > > tcp smtpd" to INETD.LST (though I don't see why it needs the original line
    > > anymore).

    >
    > The original line is necessary only if you want to listen on 25 too.


    Then I can delete it.

    By the way, I discovered yesterday why that window didn't display the final
    "d", even though that letter was present in INETD.LST. If the line is not
    followed by a newline, the final letter isn't displayed. That isn't a
    universal rule in OS/2.

    > > The new line in CONFIG.SYS should be SET SMTPH=24, is that
    > > correct?

    >
    > No, the SET SMTPH specifies the directory where files are stored after
    > receipt by SMTPD.
    > (same as for SET SMTP).


    That clarifies ever so much; I wondered where the files were. The confusion
    comes from the fact that the string "smtph" is elsewhere mentioned only in
    connection with the use of an alternate port.

    > > But the failure happened before I made any of these changes.

    >
    > What is the SET SMTP line? If it isn't a valid directory name, it won't
    > work. Error messages may appear in the INETD window, or in SMTPD.LOG.


    I didn't think to look in the INETD window (where I am on the learning
    curve, that doesn't jump to mind automatically); I will do that today.
    SMTPD.LOG doesn't exist. The SET SMTP points to an existing empty memory.

    BTW, is there a way to make the INETD window come up minimized at boot?
    There is an option like that in the TCP/IP Configuration notebook, but it
    won't let me use it, because it says I haven't set anything to start
    automatically. Yet the "Start Automatically" is checked, and the INETD
    window does start automatically.


  17. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Thu, 11 Jan 2007 10:56:26 UTC, "Stan Goodman"
    wrote:

    > BTW, is there a way to make the INETD window come up minimized at boot?
    > There is an option like that in the TCP/IP Configuration notebook, but it
    > won't let me use it, because it says I haven't set anything to start
    > automatically. Yet the "Start Automatically" is checked, and the INETD
    > window does start automatically.


    Just edit \tcpip\bin\tcpstart.cmd, and replace

    start inetd

    with

    start /min inetd

    It's one of the limitations of the configuration notebook.



  18. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Wed, 10 Jan 2007 23:57:28 UTC, "Bob Eager" opined:

    > I should have said that this solution has a minor limitation. Total
    > length of filenames and command must not exceed 1024 (max length of
    > command line). Each filename plus its leading space is 15 characters, so
    > 20 of them uses 300 bytes. Limiting the total length to 900 bytes means
    > that the rest of the filename (leading directory name) should not be
    > more than 30 characters in length. Unlikely to be a problem but I
    > mention it in case.


    Not so minor if the ISP's SMTP server requires authentication. So the
    command has to include that server's name, my username (which is of the form
    user@domain), and my password. The command, less directory name and
    filename, comes out at about 65 characters. I think I might be able to send
    files 10 or so at a time; given a mailing list of 100 names with a
    five-minute pause between groups, this would take nearly an hour.

    I could shorten the time by sending groups one after another, and setting
    loop with a longer wait between distributions. If I do that, at what point
    does session end, from the point of view of the ISP? Is it the length of the
    interval between individual messages? Or something else?

    > Of course, the REXX script can set the directory to be the default to
    > start with, by using:
    >
    > call directory value('SMTP',,'OS2ENVIRONMENT')
    >
    > then:
    >
    > f.i = filespec("name", f.i) to strip off the leading directory
    > name before concatenating into s.
    >
    > and then the limit is about 68 messages per loop.
    >
    >



  19. Re: Limitation on the number of subscribers to a MajorMajor mailing list/

    On Fri, 12 Jan 2007 19:23:49 UTC, "Stan Goodman"
    wrote:

    > On Wed, 10 Jan 2007 23:57:28 UTC, "Bob Eager" opined:
    >
    > > I should have said that this solution has a minor limitation. Total
    > > length of filenames and command must not exceed 1024 (max length of
    > > command line). Each filename plus its leading space is 15 characters, so
    > > 20 of them uses 300 bytes. Limiting the total length to 900 bytes means
    > > that the rest of the filename (leading directory name) should not be
    > > more than 30 characters in length. Unlikely to be a problem but I
    > > mention it in case.

    >
    > Not so minor if the ISP's SMTP server requires authentication. So the
    > command has to include that server's name, my username (which is of the form
    > user@domain), and my password. The command, less directory name and
    > filename, comes out at about 65 characters. I think I might be able to send
    > files 10 or so at a time; given a mailing list of 100 names with a
    > five-minute pause between groups, this would take nearly an hour.


    Not at all. Assume a group of 20 files, each 15 characters plus 30
    characters for directory name; as I said, 900 bytes. Add the
    authentication, server name, etc and that's another 65. That's still
    only 965 characters; remember that one invocation sends all of the files
    in that group. The few additional characters for authentication are
    noise, really.

    So 20 at a time is not a problem. Even then, by using the 'current
    directory' and avoiding a pathname you could treble that to 60 (which is
    more than the ISP accepts anyway).

    > I could shorten the time by sending groups one after another, and setting
    > loop with a longer wait between distributions. If I do that, at what point
    > does session end, from the point of view of the ISP? Is it the length of the
    > interval between individual messages? Or something else?


    It's each session. A session is one invocation of the 'smtp' program. I
    doubt that the ISP is going to check across sessions. Note that my REXX
    script is a previous post did *not* pause between successive invocations
    of 'smtp'; it sent all files (20 at a time) without pause. It then
    paused for a while before checking for new files; that pause is as short
    or long as you want, balancing system load against timely delivery. 100
    files would take me a minute or two.

    > > Of course, the REXX script can set the directory to be the default to
    > > start with, by using:
    > > call directory value('SMTP',,'OS2ENVIRONMENT')
    > > then:
    > > f.i = filespec("name", f.i) to strip off the leading directory
    > > name before concatenating into s.
    > >
    > > and then the limit is about 68 messages per loop.


    This still applies even with longer command and parameters; 60 files is
    achievable and in excess of what you need.



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2