🚀 go-pugleaf

On Tue, 31 Jul 2012 12:17:38 +0100 (BST), in article
     <20120731.1117.12070181snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - hi; in article, <20120727.1344.929633snz@twoplaces.co.uk>,
>            simon@twoplaces.co.uk "Simon Turner" helpfully advised:
> >
> >The following new builds can by downloaded from my ashes.org.uk web site
> >(there's no index page or anything, just files) -- if anyone wants the
> >TextWin builds or the PKLite build, let me know:
> >
> >http://www.ashes.org.uk/gremnos/lrge_03e.zip    Large build
> 
>         - not yet looked at; i'll look back to check out what the large
>         build allowed me to do, that the lite dropped (iirc, i could
>         allow privileged friends to telnet me, and to telnet myself and
>         write stuff whilst online - i don't remember aught else now).

I'm afraid the old telnettable mailbox interface disappeared even from
the Large build in v0.3 (2002), when NNTP posting was added.

Lite loses the following things that are present in Large (in no
particular order):

 * Packet driver interface
 * Packet tracing
 * IP packet filtering
 * RIP routing
 * Domain name server
 * Finger server
 * FTP server
 * ttylink server
 * Remote server (allows remote user to kick/exit/reboot your machine)
 * Remote command (allows sending of commands to a remote server)
 * DOS shell multitasker
 * Shell out with '!'

> >http://www.ashes.org.uk/gremnos/lite_03e.zip    Lite build
> >http://www.ashes.org.uk/gremnos/pplt_03e.zip    ppint's custom Lite build
> 
>         - downloaded and unzipped, many thanks; not yet investigated,
>         which i should probably try to do sometime before i'm forcibly
>         migrated - which i'm still dreading); but does your having
>         thoughtfully provided me (and potentially others) with a new
>         pplite build mean that the ~\demon\mailkill file will have any
>         effect upon mail collected by pop3 - or have you kept the pplt
>         version because the 03e net.exe retains the ability to accept
>         mail by smtp?

Mailkill works the same as ever: incoming POP3 mail is effectively
offered to the SMTP server, just as though it was arriving by SMTP, and
if the server rejects it (mailkill, unknown user etc.), the message is
deleted unread from the POP3 server instead of being downloaded.
(Unless you've set "pop3 leave on", in which case the deletion doesn't
occur.)

The SMTP server is essential to the operation of the POP3 collection, so
the ability to accept mail by SMTP will remain.  (If nothing else, I
rely on it myself!)

(For the benefit of others, the ppLite version differs from the normal
Lite only in that it doesn't insist on you receiving messages to
postmaster: normally you aren't allowed to mailkill postmaster, and
postmaster is always a known user even if not listed in the FTPUSERS
file, but the ppLite version removes those restrictions.)

>         - i'd completely forgotten john's http grabber command syntax,
>         so it was a try-and-retry set of variations before pplt_03e.zip
>         was successfully grabbed :-)

Good point!  For the benefit of anyone else who doesn't know (or can't
remember 8-) how John's HTTP grabber works, these are the notes from the
source file:

  http url [options]

  where options are one or more of:

    file=
        if no filename follows the '=', the file isn't stored
        and view is implied.

    force
        Even the header is stored.

    view
        The file content is displayed.  No pause after n lines,
        might add that later?
        The file is still stored, unless 'file=' is used.

    link
        View the links.  Turn off the 'view' option.  So,
        if you use it with 'file=', put it after that, not
        before, otherwise you'll view the whole file.
        This option is experimental and might be removed
        eventually.

    label
        Add a line at the start of the file, to show where this
        file was fetched from.

    head
        Use the HEAD form of command instead of GET.  This fetches
        only the header of the file.

  Script file support

    http @myscript

  This variant reads from the file 'myscript', so that a list of
  URLs can be prepared offline.  Options can be set within the
  script file, and/or on the line invoking the script (in the
  latter case, the options are then applied to all lines within
  the script).  Blank lines in the script are ignored.


> >    pop3 collect pop3.demon.co.uk host oldpass *env
> 
>         - *nods*  could prove useful - but if clueless+witless were
>         going to leave the old system up and running for long, they
>         could equally well let customers remain on it, couldn't they
>         </forlorn devout wish> - ?

Sadly I don't believe there is any chance of the old server remaining in
service, not least because they don't seem to have anybody left that
knows anything about it.  Demon have clearly nailed their colours to the
mast of outsourcing e-mail to MS.  (AFAICS the new system is entirely
external: the servers and the management portal are MS machines, not
Demon's.)

However, you retain access to the old server for 30 days after
migration, to collect any mail that might still get sent there, so the
*ENV code remains.  (The wording in the migration mail is that the old
mail account "will stop working 30 days after you have been migrated".)

> >* To collect mail from the administrator username on the new system and
> >  have it sent to local user "administrator", run this (substituting
> >  your real hostname and new POP3 password as appropriate):
> >    pop3 collect mail.demon.co.uk administrator@host.demon.co.uk newpass
> 
>         - iiuc, it is (will be, for me) possible to re-name the local
>         (= on the new system) user, "administrator", to something else,
>         and then to create a new user, "administrator", without the
>         administrator privileges: i do not yet know whether this will
>         divert all the spam sent to non-existent-usernames@i-m-t.dcu
>         to this new, unprivileged, "administrator" user on the new
>         system - but i hope so, as such junkmail outnumbers legitimate
>         mail to i-m-t by between 50 and 100:1.

Demon's documentation on the new mail system, and in particular the
specialness of "administrator" is, as you would expect, vague, confusing
and contradictory.

It's not entirely clear from the documentation what happens if you
remove "administrator" from the list of addresses for the initial
administrator username and re-assign it to a different username, nor
whether it is the "administrator" address or that original default
username's mailbox that is "special" (i.e. is the destination for mail
addressed to unknown users).  I'm intending to have a play with it, and
will report back; since I only receive one or two bits of real mail per
year to my Demon account, it won't be a complete disaster if I
permamently lose the ability to receive stuff to unkown users!

However, I can't see why you would want to assign the "administrator"
address to a diffeent username anyway: the fact that the administrator
username is privileged (i.e. logging in to the management portal with
that username/password allows you to add/delete users etc.) doesn't have
any implications for the mail that arrives in its mailbox.  Just create
one or more extra usernames (possibly with multiple addresses for each
username) that will receive the genuinely-addressed mail, and leave the
misaddressed spam uncollected in the administrator username's mailbox.

>         - and it does work, i can then leave everything placed by c+w
>         on the new, unprivileged "administrator" user's mail on their
>         machine until they choose to delete it. (- touch wood.)

Yup (although I think they may bounce it back rather than silently
delete it; it is, of course, very unclear).  I may try it at some stage!

>         - i do not, for fairly obvious reason, given the spam:legitimate
>         mail ratio, currently have a "default deliver" - or any other
>         default line - in my alias file: will this upset pp_03e at all?

Nope; it's happy to delete mail sent to unknown usernames unread.  (As
Pete found out when testing it and forgetting to add "*env" to the end
of the command: the recipient name ended up being the default "unknown",
which wasn't a known user...)

> >        DO NOT try using *env with the new system: it doesn't work, and
> >        will result in all messages being sent to local-user "*env" with
> >        possibly catastrophic consequences [...]
> 
>         *nod*  thanks for the explicit warning & instruction.

My build has code in it to rewrite some of the more common "legal for
addresses, but not for DOS filenames" characters to other safe ones;
realising the potential for accidental use of *env to cause mail to be
lost, I think I may enable that code for everyone in the next build.

> >pop3 bounce [on | off]
> >
> >        [...]  Default is off: leave it that way!
> 
>         - i currently (pplt_03d) (unmigrated) reject ~50-98% of mail
>         getting through to the smtp queueue on the grounds of sender
>         or recipient, using a *lot* of regexps, and every now & then
>         adding a new line: i don't particularly want to send dsns to
>         most of the apparent senders, but don't know how not to, with
>         the current smtp mail delivery system, and amn't sure whether
>         the new, post-forced migration, pop3 system will/can use my
>         mailkill file at all.  (i'd've guessed not, but am hoping...)

No worries: with POP3 collection and "pop3 bounce off", the mailkilled
messages will simply vanish in a puff of logic.

I don't know what the current system does if you reject the mail it's
trying to send to you: I assume it sends a DSN to the poor sap whose
address has been forged as the envelope-from, but perhaps not.  (If you
want to find out, I can send a message to an invalid username @imt and
tell you if I get a DSN back!)

> >[*] The "rsh" command never worked anyway: it was unimplemented, and
> >just returned 0...
> 
>         - i do not recall what it was _meant_ to do - and i've never
>         used rlogin, not least because unscheduled & unadvised power
>         cuts used to be fairly common here (and still occur a couple
>         of times a year), with attendant unpredictable supply spikes.
>         leaving i-m-t powered on unattended didn't (and still doesn't)
>         seem sensible, despite using an anti-spike spelled socket.

"rlogin" allows you to log in to a remote (typically UN*X) computer, not
the other way around.  "rsh" is a restricted form that allows you to run
a command on a remote system.

>         - love, ppint. (just been given my hospital date: 21/8/12)

Good luck!

Demon are probably preparing your migration for just that date... 8-(

-- 
Simon Turner                                    DoD #0461
simon@twoplaces.co.uk
    Trust me -- I know what I'm doing!          -- Sledge Hammer