🚀 go-pugleaf

	- hi; in article, <20120801.1206.930022snz@twoplaces.co.uk>,
	     simon@twoplaces.co.uk "Simon Turner" elaborated:
>	                 "ppint. at pplay" wrote:
>>	    simon@twoplaces.co.uk "Simon Turner" helpfully advised:
[]
>>>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.

	- ah. o.k. "it was a little time ago."
>
>Lite loses the following things that are present in Large (in no
>particular order):
>
> * Packet driver interface
> * Packet tracing
> * IP packet filtering

	- is one of these two "hop check <ip address>" from the net> ?

> * RIP routing
> * Domain name server

	- is this not "domain query <ip address>" from net> ?

> * 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 '!'

	- ah; i thought i'd been able to do/use these two, once upon a time.
>
>> >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
>>
[snip]
>> 
>
>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.

	- o.k; it's taking me longer and longer dialled-up, to reject
	the spam+malawi getting through the filtering service demon/
	thus/clueless+witless've hired; the prospect of being able to
	abandon it with them is one of the few potential advantages of
	the new "system" i could see - was this then a mirage?

>(Unless you've set "pop3 leave on", in which case the deletion doesn't
>occur.)

	- o.k;
>
>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!)

	- "phew!"
>
>(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.)

	- it allows me/the user, having noted a surge in the amount of
	spam and/or malawi aimed at postmaster in the mail queued up on
	the punt-3 cluster, to apply the ultimate sanction of closing
	the postmaster@yourdomain.dcu and bounce the lot - just, don't
	forget to re-open postmaster@ afterwards...
>
>>	- 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.

	- thanks for listing, "syntacting" (sorry) & explaining them.
>
>> >    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.)

	- wheee!  well, thus plc's manglement did avow there was no
	longer any such thing as demon internet - it was just a brand
	of thus plc... ghu only knows what clueless+witless think.
>
>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".)

	- will the last old stager to be forcibly emigrated please turn
	off the lights - ?
>
>> >* 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!

	- *nods*  - you posted to d.s regarding your investigations into
	this (inter alia): i've responded to that, cross-posting my reply
	here in case anyone reading dipspc missed it, as had an interest.
>
>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.

	- i've a suspicion that c+w may write to administrator@, rather
	than to postmaster@, if ever they wish to contact us post-forced
	mail emigration.
>
>>	- 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!

	- you've discovered it does not work like that ( :-( ) - see now
	cross-posted other thread, if you've not been following simon's
	reports of his investigations on d.s.
>
>>	- 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.

	- good, good; so, if i can't isolate all the junk+malawi in a
	wotsit i never tryto collect mail from, at least most of it'll
	usually disappear.

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

	- i actually created a user alias, "unknown", whilst trying to
	get c+w's incompetently-forged email to us to download by smtp;
	i wonder...
>
>> >        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.

	- 'twould seem safer, yes.
>
>> >pop3 bounce [on | off]
>> >
>> >        [...]  Default is off: leave it that way!
[] 
>>	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.

	- *g*  - thanks for the str.  have you read much/any sheckley?
>
>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!)

	- feel welcome, should you wish to discover.
>
>>>[*] The "rsh" command never worked anyway: it was unimplemented, and
>>>just returned 0...
>>[]
>
>"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.

	- o.k.
>
>>	- love, ppint. (just been given my hospital date: 21/8/12)
>
>Good luck!
>
>Demon are probably preparing your migration for just that date... 8-(

	- and thank-you for that thought - yes, it'd be about par for
	this year (so far).  just what i want to come home to. *shudder*

	- love, ppint.
	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
 "No creature without tentacles had ever developed true intelligence."
                - "Hunting Problem" Robert Sheckley