🚀 go-pugleaf

In article <20120721.0929.494snz@cj4386.demon.co.uk>
           colin@cj4386.demon.co.uk "colin may" writes:

> I've received notice of mail migration. Can KA9Q be configured to work with
> this? Any advice will be appreciated.
> 
> Many thanks and here's hoping.
> 
> Still using MSDOS 6.22.

On dialup?  I'm in the same situation (though haven't yet received the 
email).  It would appear not -- at least not without a serious rewrite 
of KA9Q/GremNOS -- judging by various posts in demon.service over the 
last few months.  Even the POP3 versions will cease to work.  I dont 
have the thread subjects/message-ids to hand so can only suggest 
trawling through there.

After 18 years with Demon I'm planning on leaving as soon as "the 
email" arrives :-(  Or rather, gets delivered; the notification has 
been sitting on punt3 for ages, but so badly formed as to be 
undeliverable!

Sorry for being the bearer of bad news.

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  Andr� Gide

On Saturday, in article <1342892391snz@nospam.demon.co.uk>
     pete@nospam.demon.co.uk wrote:

> In article <20120721.0929.494snz@cj4386.demon.co.uk>
>            colin@cj4386.demon.co.uk "colin may" writes:
>
> > I've received notice of mail migration. Can KA9Q be configured to work with
> > this? Any advice will be appreciated.
> >
> > Many thanks and here's hoping.
> >
> > Still using MSDOS 6.22.
>
> On dialup?  I'm in the same situation (though haven't yet received the
> email).  It would appear not -- at least not without a serious rewrite
> of KA9Q/GremNOS -- judging by various posts in demon.service over the
> last few months.  Even the POP3 versions will cease to work.  I dont
> have the thread subjects/message-ids to hand so can only suggest
> trawling through there.
>
> After 18 years with Demon I'm planning on leaving as soon as "the
> email" arrives :-(  Or rather, gets delivered; the notification has
> been sitting on punt3 for ages, but so badly formed as to be
> undeliverable!
>
> Sorry for being the bearer of bad news.
>
> Pete

High Pete,

ThankS for your reply.  I read the threads on demon.service. I ALSO have been
with Demon 18 years, Reluctant TO leAve. Do you know if KA9Q AND VARIANTS ARE
configurable with otheR ISPs?

A none friendly windows user (thats putting it mildly).

In article <20120721.0929.494snz@cj4386.demon.co.uk>, colin may
<colin@cj4386.demon.co.uk> writes

>I've received notice of mail migration. Can KA9Q be configured to work with
>this? Any advice will be appreciated.

if you have a version of KA9Q that can handle POP3 then that can be
configured to work ...

-- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

On Sunday, in article <uSqYShPLqHDQFAnU@highwayman.com>
     richard@highwayman.com "Richard Clayton" wrote:

> In article <20120721.0929.494snz@cj4386.demon.co.uk>, colin may
> <colin@cj4386.demon.co.uk> writes
> 
> >I've received notice of mail migration. Can KA9Q be configured to work with
> >this? Any advice will be appreciated.
> 
> if you have a version of KA9Q that can handle POP3 then that can be
> configured to work ...

From what I've heard on demon.service, the new platform may require
STARTTLS encryption for POP3, which would render my POP3-enabled GremNOS
unusable without quite a lot of extra work.  I'll find out for sure on
Wednesday afternoon, which is when I'm being migrated... 8-(

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

On Monday, in article
     <20120723.1320.929266snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Sunday, in article <uSqYShPLqHDQFAnU@highwayman.com>
>      richard@highwayman.com "Richard Clayton" wrote:
>
> > In article <20120721.0929.494snz@cj4386.demon.co.uk>, colin may
> > <colin@cj4386.demon.co.uk> writes
> >
> > >I've received notice of mail migration. Can KA9Q be configured to work with
> > >this? Any advice will be appreciated.
> >
> > if you have a version of KA9Q that can handle POP3 then that can be
> > configured to work ...
>
> From what I've heard on demon.service, the new platform may require
> STARTTLS encryption for POP3, which would render my POP3-enabled GremNOS
> unusable without quite a lot of extra work.  I'll find out for sure on
> Wednesday afternoon, which is when I'm being migrated... 8-(
>

Thanks for all the responses. I was supposed to be migrated at 1pm today.  How
would I know?

On Monday, in article
     <20120723.1547.519snz@cj4386.demon.co.uk>
     colin@cj4386.demon.co.uk "colin may" wrote:

> On Monday, in article
>      <20120723.1320.929266snz@twoplaces.co.uk>
>      simon@twoplaces.co.uk "Simon Turner" wrote:
> 
> > On Sunday, in article <uSqYShPLqHDQFAnU@highwayman.com>
> >      richard@highwayman.com "Richard Clayton" wrote:
> >
> > > In article <20120721.0929.494snz@cj4386.demon.co.uk>, colin may
> > > <colin@cj4386.demon.co.uk> writes
> > >
> > > >I've received notice of mail migration. Can KA9Q be configured to
> > > >work with this? Any advice will be appreciated.
> > >
> > > if you have a version of KA9Q that can handle POP3 then that can be
> > > configured to work ...
> >
> > From what I've heard on demon.service, the new platform may require
> > STARTTLS encryption for POP3, which would render my POP3-enabled GremNOS
> > unusable without quite a lot of extra work.  I'll find out for sure on
> > Wednesday afternoon, which is when I'm being migrated... 8-(
> >
> 
> Thanks for all the responses. I was supposed to be migrated at 1pm
> today.  How would I know?

I'm not quite sure what question you're asking, so I'll have a bash at
answering two variants.  Sorry this is rather long; I hope one of them
is what you wanted!

Q1. How would I know whether I've been migrated or not?

A1. After migration, all mail will go to the new platform and not to the
    old one.  So, arrange for some mail to be sent to you and see if it
    arrives: if so, you haven't been migrated yet; if not, you have.
    Note that the new platform uses new host names for mail sending
    (SMTP) and collection (OPP3): the old one used post.dcu for sending
    and pop3.dcu for collection; the new one uses smtp.dcu for sending
    and mail.dcu for collection.

    Note that your KA9Q setup may spot the attempt to send mail to
    yourself and deliver it locally instead of going via demon; if you
    like, I can send you a test message instead.  Let me know.

    If you've recently been receiving these lovely virus-laden booking
    confirmation messages, you may already have rather a lot of them
    waiting for you: after only getting 10-20 per day on average for
    several weeks, I seem to have 100+ waiting for me at the moment!  I
    would like to think that the new platform's "improved" antispam
    stuff would block these, but report in demon.service don't sound all
    that encouraging...


Q2. How would I know whether KA9Q-type POP3 collection will work or not?

A2. Try a normal text (i.e. unencrypted) POP3 session to the new server.
    Note that this relies on you being able to type things accurately to
    a live POP3 telnet session (correcting errors with backspace may not
    work as you expect), so only do it if you're reasonably confident
    that you can type things accurately first time.  The test would be
    more useful if there is some mail waiting for you (so do the above
    test first and make sure it doesn't get sent to you by the old
    system, meaning that it should be waiting for you on the new one).

    Your migration mail should tell you the name of the default mailbox
    they have set up for you (administrator@yourhost.demon.co.uk, where
    I presume yourhost will be cj4386) and its password (indicated by
    stars in the sample below).

    Run "telnet mail.demon.co.uk 110" and you should get a dialogue with
    the new POP3 server somewhat like this ("<-" means stuff the server
    sends to you, "->" means stuff you send to it by typing and pressing
    return -- note that the commands I sent were in capitals, e.g. USER
    rather than user, but you can use lowercase if you prefer):

      <- +OK The Microsoft Exchange POP3 service is ready.
      -> USER administrator@********.demon.co.uk
      <- +OK
      -> PASS ********
      <- +OK User successfully logged on.
      -> STAT
      <- +OK 0 0

    If this returns something more like "+OK 5 15354", it means there
    are 5 messages in your mailbox, with combined size 15354 bytes.  If
    so, go on to try some other commands like LIST and TOP as shown
    here:

      -> LIST
      <- +OK 5 15354
      <- [list of message numbers and lengths, one per line]
      <- .
      -> TOP 1 5
      <- 
      <- +OK
      <- [message header]
      <- 
      <- [first 5 lines of message body]
      <- .

    No matter what happens, you should send the QUIT command to end the
    telnet session (in fact, this can be typed at almost any point to
    end the session cleanly if you're not confident about continuing):

      -> QUIT
      <- +OK Microsoft Exchange Server 2010 POP3 server signing off.

    Let us know how you get on; or if you're not sure about doing this
    sort of stuff, and can manage without your mail for a couple of
    days, wait until Wednesday afternoon and I'll run the tests and
    report back to the group.

    As you may have guessed, I was able to have an unencrypted
    conversation with the new server, but I haven't been migrated yet so
    I don't know if that would remain the case after migration.  (I also
    don't know whether connecting via a Demon IP address would make a
    difference; my test was from a non-Demon host.)

If the new platform will accept plain unenecrypted POP3 for mail
collection, I've got a version of GremNOS with POP3 collection
integrated in to the SMTP system that may work for you...

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

On Monday, in article
     <20120723.1659.929275snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Monday, in article
>      <20120723.1547.519snz@cj4386.demon.co.uk>
>      colin@cj4386.demon.co.uk "colin may" wrote:
>
> > On Monday, in article
> >      <20120723.1320.929266snz@twoplaces.co.uk>
> >      simon@twoplaces.co.uk "Simon Turner" wrote:
> >
> > > On Sunday, in article <uSqYShPLqHDQFAnU@highwayman.com>
> > >      richard@highwayman.com "Richard Clayton" wrote:
> > >
> > > > In article <20120721.0929.494snz@cj4386.demon.co.uk>, colin may
> > > > <colin@cj4386.demon.co.uk> writes
> > > >
> > > > >I've received notice of mail migration. Can KA9Q be configured to
> > > > >work with this? Any advice will be appreciated.
> > > >
> > > > if you have a version of KA9Q that can handle POP3 then that can be
> > > > configured to work ...
> > >
> > > From what I've heard on demon.service, the new platform may require
> > > STARTTLS encryption for POP3, which would render my POP3-enabled GremNOS
> > > unusable without quite a lot of extra work.  I'll find out for sure on
> > > Wednesday afternoon, which is when I'm being migrated... 8-(
> > >
> >
> > Thanks for all the responses. I was supposed to be migrated at 1pm
> > today.  How would I know?
>
> I'm not quite sure what question you're asking, so I'll have a bash at
> answering two variants.  Sorry this is rather long; I hope one of them
> is what you wanted!
>
> Q1. How would I know whether I've been migrated or not?
>
> A1. After migration, all mail will go to the new platform and not to the
>     old one.  So, arrange for some mail to be sent to you and see if it
>     arrives: if so, you haven't been migrated yet; if not, you have.
>     Note that the new platform uses new host names for mail sending
>     (SMTP) and collection (OPP3): the old one used post.dcu for sending
>     and pop3.dcu for collection; the new one uses smtp.dcu for sending
>     and mail.dcu for collection.
>
>     Note that your KA9Q setup may spot the attempt to send mail to
>     yourself and deliver it locally instead of going via demon; if you
>     like, I can send you a test message instead.  Let me know.
>
>     If you've recently been receiving these lovely virus-laden booking
>     confirmation messages, you may already have rather a lot of them
>     waiting for you: after only getting 10-20 per day on average for
>     several weeks, I seem to have 100+ waiting for me at the moment!  I
>     would like to think that the new platform's "improved" antispam
>     stuff would block these, but report in demon.service don't sound all
>     that encouraging...
>
>
> Q2. How would I know whether KA9Q-type POP3 collection will work or not?
>
> A2. Try a normal text (i.e. unencrypted) POP3 session to the new server.
>     Note that this relies on you being able to type things accurately to
>     a live POP3 telnet session (correcting errors with backspace may not
>     work as you expect), so only do it if you're reasonably confident
>     that you can type things accurately first time.  The test would be
>     more useful if there is some mail waiting for you (so do the above
>     test first and make sure it doesn't get sent to you by the old
>     system, meaning that it should be waiting for you on the new one).
>
>     Your migration mail should tell you the name of the default mailbox
>     they have set up for you (administrator@yourhost.demon.co.uk, where
>     I presume yourhost will be cj4386) and its password (indicated by
>     stars in the sample below).
>
>     Run "telnet mail.demon.co.uk 110" and you should get a dialogue with
>     the new POP3 server somewhat like this ("<-" means stuff the server
>     sends to you, "->" means stuff you send to it by typing and pressing
>     return -- note that the commands I sent were in capitals, e.g. USER
>     rather than user, but you can use lowercase if you prefer):
>
>       <- +OK The Microsoft Exchange POP3 service is ready.
>       -> USER administrator@********.demon.co.uk
>       <- +OK
>       -> PASS ********
>       <- +OK User successfully logged on.
>       -> STAT
>       <- +OK 0 0
>
>     If this returns something more like "+OK 5 15354", it means there
>     are 5 messages in your mailbox, with combined size 15354 bytes.  If
>     so, go on to try some other commands like LIST and TOP as shown
>     here:
>
>       -> LIST
>       <- +OK 5 15354
>       <- [list of message numbers and lengths, one per line]
>       <- .
>       -> TOP 1 5
>       <-
>       <- +OK
>       <- [message header]
>       <-
>       <- [first 5 lines of message body]
>       <- .
>
>     No matter what happens, you should send the QUIT command to end the
>     telnet session (in fact, this can be typed at almost any point to
>     end the session cleanly if you're not confident about continuing):
>
>       -> QUIT
>       <- +OK Microsoft Exchange Server 2010 POP3 server signing off.
>
>     Let us know how you get on; or if you're not sure about doing this
>     sort of stuff, and can manage without your mail for a couple of
>     days, wait until Wednesday afternoon and I'll run the tests and
>     report back to the group.
>
>     As you may have guessed, I was able to have an unencrypted
>     conversation with the new server, but I haven't been migrated yet so
>     I don't know if that would remain the case after migration.  (I also
>     don't know whether connecting via a Demon IP address would make a
>     difference; my test was from a non-Demon host.)
>
> If the new platform will accept plain unenecrypted POP3 for mail
> collection, I've got a version of GremNOS with POP3 collection
> integrated in to the SMTP system that may work for you...
>

High Simon,

Bit over my head, but I tried the "telnet mail.demon.co.uk 110" it came
back with the message "pop3 microsoft exchange ready ok" typing anyhing after
this sends back the message "error protocol 19". I tried to email you, no go.
Must have been migrated. Version of KA9Q is gremnos v0.3d.


Colin

On Monday, in article
     <20120723.2213.522snz@cj4386.demon.co.uk>
     colin@cj4386.demon.co.uk "colin may" wrote:

> On Monday, in article
>      <20120723.1659.929275snz@twoplaces.co.uk>
>      simon@twoplaces.co.uk "Simon Turner" wrote:
> 
> > Q2. How would I know whether KA9Q-type POP3 collection will work or not?
> >
> > A2. Try a normal text (i.e. unencrypted) POP3 session to the new server.
> >     [...]
> >
> >     Run "telnet mail.demon.co.uk 110" and you should get a dialogue with
> >     the new POP3 server somewhat like this [...]
> >
> > If the new platform will accept plain unenecrypted POP3 for mail
> > collection, I've got a version of GremNOS with POP3 collection
> > integrated in to the SMTP system that may work for you...

> Bit over my head, but I tried the "telnet mail.demon.co.uk 110" it
> came back with the message "pop3 microsoft exchange ready ok" typing
> anyhing after this sends back the message "error protocol 19". I tried
> to email you, no go.  Must have been migrated.

I did eventually receive your mail this morning; your first attempt to
send it probably fell foul of the "greylisting" applied by the people
who host my domain, whereby they initially refuse to accept the mail
with a temporary error, then if you try again after five minutes or so
they will accept it.  (This is an anti-spam measure: spammers often give
up if the first attempt doesn't work, but proper mail systems should
continue to try sending it and eventually get through.)

So at least your outbound sending works; but I doubt you'll see my
reply, because it went to the new platform -- mx1.demon.co.uk -- rather
than punt-*.demon.net as would have been the case before migration.

(Raising the SMTP tracing level will let you see the initial 220
response from the server, which is quite different on the new platform:
"220 smtp.demon.co.uk ESMTP" rather than the old "220
anchor-hub.mail.demon.net ESMTP <date>".)

Disappointing to hear that telnetting to the new POP3 server didn't
work; is there any chance you could try it again, and tell us *exactly*
what it said before you started typing?  And exactly what you typed (if
anything) before it produced the error?  (Obscure hostnames and/or
passwords by all means, but otherwise let us know the precise keys you
pressed.)  Protocol error 19 from MS Exchange seems to mean
"unrecognised command", which suggests it might be some kind of typo
rather than something more fundamental.  (Fingers crossed...)

I can run some tests for myself once I've been migrated tomorrow
afternoon, but the one aspect of your setup I can't reproduce is a
direct connection from a Demon host rather than an external one (I
haven't connected through Demon for years, and don't particularly want
to have to find a modem, an old machine with a serial port etc. just so
I can try it.)

> Version of KA9Q is gremnos v0.3d.

OK, thanks.  Could you tell me the size of the NET.EXE file in bytes, so
I can work out which of the five possible variants you're using?

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

On Tuesday, in article
     <20120724.1016.929403snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Monday, in article
>      <20120723.2213.522snz@cj4386.demon.co.uk>
>      colin@cj4386.demon.co.uk "colin may" wrote:
>
> > On Monday, in article
> >      <20120723.1659.929275snz@twoplaces.co.uk>
> >      simon@twoplaces.co.uk "Simon Turner" wrote:
> >
> > > Q2. How would I know whether KA9Q-type POP3 collection will work or not?
> > >
> > > A2. Try a normal text (i.e. unencrypted) POP3 session to the new server.
> > >     [...]
> > >
> > >     Run "telnet mail.demon.co.uk 110" and you should get a dialogue with
> > >     the new POP3 server somewhat like this [...]
> > >
> > > If the new platform will accept plain unenecrypted POP3 for mail
> > > collection, I've got a version of GremNOS with POP3 collection
> > > integrated in to the SMTP system that may work for you...
>
> > Bit over my head, but I tried the "telnet mail.demon.co.uk 110" it
> > came back with the message "pop3 microsoft exchange ready ok" typing
> > anyhing after this sends back the message "error protocol 19". I tried
> > to email you, no go.  Must have been migrated.
>
> I did eventually receive your mail this morning; your first attempt to
> send it probably fell foul of the "greylisting" applied by the people
> who host my domain, whereby they initially refuse to accept the mail
> with a temporary error, then if you try again after five minutes or so
> they will accept it.  (This is an anti-spam measure: spammers often give
> up if the first attempt doesn't work, but proper mail systems should
> continue to try sending it and eventually get through.)
>
> So at least your outbound sending works; but I doubt you'll see my
> reply, because it went to the new platform -- mx1.demon.co.uk -- rather
> than punt-*.demon.net as would have been the case before migration.
>
> (Raising the SMTP tracing level will let you see the initial 220
> response from the server, which is quite different on the new platform:
> "220 smtp.demon.co.uk ESMTP" rather than the old "220
> anchor-hub.mail.demon.net ESMTP <date>".)
>
> Disappointing to hear that telnetting to the new POP3 server didn't
> work; is there any chance you could try it again, and tell us *exactly*
> what it said before you started typing?  And exactly what you typed (if
> anything) before it produced the error?  (Obscure hostnames and/or
> passwords by all means, but otherwise let us know the precise keys you
> pressed.)  Protocol error 19 from MS Exchange seems to mean
> "unrecognised command", which suggests it might be some kind of typo
> rather than something more fundamental.  (Fingers crossed...)
>
> I can run some tests for myself once I've been migrated tomorrow
> afternoon, but the one aspect of your setup I can't reproduce is a
> direct connection from a Demon host rather than an external one (I
> haven't connected through Demon for years, and don't particularly want
> to have to find a modem, an old machine with a serial port etc. just so
> I can try it.)
>
> > Version of KA9Q is gremnos v0.3d.
>
> OK, thanks.  Could you tell me the size of the NET.EXE file in bytes, so
> I can work out which of the five possible variants you're using?
>

High Simon,

Went to bed and relised I hadn't activated the account (getting old and all
that). I'll be doing it this afternoon and let you know how it went, here's
hoping.

Gremnos v0.3d large 394524 bytes.

On Tuesday, in article
     <20120724.1016.929403snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> I can run some tests for myself once I've been migrated tomorrow
> afternoon, but the one aspect of your setup I can't reproduce is a
> direct connection from a Demon host rather than an external one (I
> haven't connected through Demon for years, and don't particularly want
> to have to find a modem, an old machine with a serial port etc. just so
> I can try it.)

Brief post-migration follow-up: from my non-Demon IP, I can use
plain-text POP3 to port 110 and get at the messages, so (unless this is
a temporary ability or Demon subsequently decide to remove it) I can
retrieve messages from the new mail.demon.co.uk server with my
POP3-enabled version of GremNOS.  Phew!

I'm not quite sure whether the same is true from a Demon IP address,
since Colin is still unable to get plain-text POP3 to work, but I'm
hoping that turns out to be finger trouble; I can't imagine even Demon,
with their legendary ability to get things wrong, insisting on encrypted
POP3 session from within Demon but not from without.  Of course, ICBW.

However, I discovered that my GremNOS code was unable to pick out the
MAIL FROM address from the Return-Path: header field, because (shock!
horror!) the Return-Path: field created by the oh-so-wonderful new
platform is non-compliant with the RFCs defining the SMTP message
format.  Why am I not surprised?  So I'll have to fix my code to work
around the broken new platform before it's ready for release; sorry
about that!

(If you want to know, all of the SMTP message format RFCs -- 822, 2822
and 5322, which is the latest one -- require the Return-Path: field to
have an address enclosed in angle brackets; but the new platform doesn't
include the brackets.  Good old MS!)

So, tentatively for now, there does appear to be Life After Migration.

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

	- hi; in article, <20120725.1643.929496snz@twoplaces.co.uk>,
	     simon@twoplaces.co.uk "Simon Turner" appended:
>	      simon@twoplaces.co.uk "Simon Turner" wrote:
>> I can run some tests for myself once I've been migrated tomorrow
>> afternoon, but the one aspect of your setup I can't reproduce is a
>> direct connection from a Demon host rather than an external one (I
>> haven't connected through Demon for years, and don't particularly want
>> to have to find a modem, an old machine with a serial port etc. just so
>> I can try it.)
>
>Brief post-migration follow-up: from my non-Demon IP, I can use plain-
>text POP3 to port 110 and get at the messages, so (unless this is a
>temporary ability or Demon subsequently decide to remove it) I can
>retrieve messages from the new mail.demon.co.uk server with my POP3-
>enabled version of GremNOS.  Phew!

	- phew, indeed!
>
>I'm not quite sure whether the same is true from a Demon IP address,
>since Colin is still unable to get plain-text POP3 to work, but I'm
>hoping that turns out to be finger trouble; I can't imagine even Demon,
>with their legendary ability to get things wrong, insisting on encrypted
>POP3 session from within Demon but not from without.

	- not yet been forcibly migrated, thank any divinities there be.

>Of course, ICBW.

	- fniggers, yees, gels'n'rams lla corseds. dan choutnig odow...
>
>However, I discovered that my GremNOS code was unable to pick out the
>MAIL FROM address from the Return-Path: header field, because (shock!
>horror!) the Return-Path: field created by the oh-so-wonderful new
>platform is non-compliant with the RFCs defining the SMTP message
>format.  Why am I not surprised?  So I'll have to fix my code to work
>around the broken new platform before it's ready for release; sorry
>about that!

	- watching developments with definite interest, though i've not
	very much to contribute, alas.
>
>(If you want to know, all of the SMTP message format RFCs -- 822, 2822
>and 5322, which is the latest one -- require the Return-Path: field to
>have an address enclosed in angle brackets; but the new platform doesn't
>include the brackets.  Good old MS!)

	- *sigh*  - though i do all i can to avoid them, clueless and
	witless impose 'em upon me - and thee, since thou'rt so good as
	to do the work to provide the few of us with a gremnos usable
	after this self-inspired stroke by them.
>
>So, tentatively for now, there does appear to be Life After Migration.

	- as loyal subjects of his original demonic majesty (and his
	allegedly legitimate successors), should we not have a right to
	remain upon the original system to which we signed up? (- [a])

	- thanks for persisting, simon;

	- love, a ppint. who's done nothing of effect towards finding
	out how to do broadband using (dr/ibm/ms-)dos yet, being some-
	what distracted by a (non-life-threatening) health problem

	[a] - dept. of devout *wishes*

	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
Microsoft announced recently that it had lost the source code to MS-DOS
       - Peter Jackson, PC Magazine December 1998 [p. 29]

On Wednesday, in article
     <20120725.1643.929496snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Tuesday, in article
>      <20120724.1016.929403snz@twoplaces.co.uk>
>      simon@twoplaces.co.uk "Simon Turner" wrote:
>
> > I can run some tests for myself once I've been migrated tomorrow
> > afternoon, but the one aspect of your setup I can't reproduce is a
> > direct connection from a Demon host rather than an external one (I
> > haven't connected through Demon for years, and don't particularly want
> > to have to find a modem, an old machine with a serial port etc. just so
> > I can try it.)
>
> Brief post-migration follow-up: from my non-Demon IP, I can use
> plain-text POP3 to port 110 and get at the messages, so (unless this is
> a temporary ability or Demon subsequently decide to remove it) I can
> retrieve messages from the new mail.demon.co.uk server with my
> POP3-enabled version of GremNOS.  Phew!
>
> I'm not quite sure whether the same is true from a Demon IP address,
> since Colin is still unable to get plain-text POP3 to work, but I'm
> hoping that turns out to be finger trouble; I can't imagine even Demon,
> with their legendary ability to get things wrong, insisting on encrypted
> POP3 session from within Demon but not from without.  Of course, ICBW.
>
> However, I discovered that my GremNOS code was unable to pick out the
> MAIL FROM address from the Return-Path: header field, because (shock!
> horror!) the Return-Path: field created by the oh-so-wonderful new
> platform is non-compliant with the RFCs defining the SMTP message
> format.  Why am I not surprised?  So I'll have to fix my code to work
> around the broken new platform before it's ready for release; sorry
> about that!
>
> (If you want to know, all of the SMTP message format RFCs -- 822, 2822
> and 5322, which is the latest one -- require the Return-Path: field to
> have an address enclosed in angle brackets; but the new platform doesn't
> include the brackets.  Good old MS!)
>
> So, tentatively for now, there does appear to be Life After Migration.
>

Still having no luck logging on to the new mail platform, below is what I do.

telnet mail.demon.co.uk 110
Resolving mail.demon.co.uk... trying 91.221.168.28:110
Telnet session 1 connected to mail.demon.co.uk
+OK The Microsoft Exchange POP3 service is ready.

I type in username and get the message
-ERR Protocol error  19
Type in password and get the message
-ERR Protocol error  19
Press enter again and get the message
-ERR Protocol error 20
Telnet session 1 closed: EOF
Hit enter to ccontinue

I don't think I'm doing anything wrong (might be of course). It might be as
Simon says above.

On Thursday, in article
     <20120726.1043.1snz@cj4386.demon.co.uk>
     colin@cj4386.demon.co.uk "colin may" wrote:

> Still having no luck logging on to the new mail platform, below is what I do.
> 
> telnet mail.demon.co.uk 110
> Resolving mail.demon.co.uk... trying 91.221.168.28:110
> Telnet session 1 connected to mail.demon.co.uk
> +OK The Microsoft Exchange POP3 service is ready.
> 
> I type in username and get the message
> -ERR Protocol error  19

Are you just entering the username, or are you preceding it with the
command "user"?  If not, that would explain the error 19 (which seems to
be "unknown command").

e.g. type "user administrator@yourdomain.demon.co.uk<enter>"

> Type in password and get the message
> -ERR Protocol error  19

Ditto for the password: it must be preceded by the command "pass".

e.g. type "pass yourpassword<enter>"

Let us know if that helps, or if you're still having problems.

By the way, do you have web access that will allow you to use the Email
Management Portal?

Brief GremNOS status report: non-compliant "Return-Path:" fields are now
handled, and I've fixed the bug that stopped it putting POP3 messages in
the specified mailbox[*], but at present you have to either (a) set up
separate mailboxes for all your active usernames, then collect for each
mailbox separately, or (b) leave the single "administrator" mailbox as
the catch-all and put up with all messages being put into a single
mailbox, regardless of the original recipient address.

I'm intending to add an "auto" recipient mailbox mode, which will parse
the "Received:" fields (or failing that, the "To:" and "Cc:" fields) to
try to find the original recipient, so that it stands a fighting chance
of doing the right thing if you get messages for multiple recipients in
a single mailbox (e.g. you only have the detault administrator mailbox);
it probably won't handle multiple recipient messages particularly well
(unless they all have separate mailboxes), but I think it will be as
good as can be achieved without the old *ENV feature (RIP).

[*] the code worked the way I had documented it when I wrote it, but
that wasn't how I had really intended it to work... 8-/

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

In article <20120726.1320.929535snz@twoplaces.co.uk>
           simon@twoplaces.co.uk "Simon Turner" writes:
[snip]
It's reassuring to learn that there is Life After Migration :)

I've still not been migrated -- at least I've received no notification 
of migration, and the original 671 byte email is still not budging 
from the punt.

> Brief GremNOS status report: non-compliant "Return-Path:" fields are now
> handled, and I've fixed the bug that stopped it putting POP3 messages in
> the specified mailbox[*], but at present you have to either (a) set up
> separate mailboxes for all your active usernames, then collect for each
> mailbox separately, or (b) leave the single "administrator" mailbox as
> the catch-all and put up with all messages being put into a single
> mailbox, regardless of the original recipient address.

Probably too early to ask, but is there a new POP3 zip available yet?  
And as probably the only person using "smtp queue" and delivering 
locally, will the single "administrator" mailbox suffice?  (Of course 
I'll discover this in due course, but just thought I'd ask as you've 
BTDT with the code changes.)

> I'm intending to add an "auto" recipient mailbox mode, which will parse
> the "Received:" fields (or failing that, the "To:" and "Cc:" fields) to
> try to find the original recipient, so that it stands a fighting chance
> of doing the right thing if you get messages for multiple recipients in
> a single mailbox (e.g. you only have the detault administrator mailbox);
> it probably won't handle multiple recipient messages particularly well
> (unless they all have separate mailboxes), but I think it will be as
> good as can be achieved without the old *ENV feature (RIP).

I think I'll disable all mailkill functionality at migration-time to 
ensure I miss nothing.  I assume the POP3 GremNOS just issues a delete 
for a mailkill match and logs the deletion?  If not I'll try to 
implement something like this when the new source becomes available.

Thanks for all your work on this, Simon.

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  Andr� Gide

On Thursday, in article
     <20120726.1320.929535snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Thursday, in article
>      <20120726.1043.1snz@cj4386.demon.co.uk>
>      colin@cj4386.demon.co.uk "colin may" wrote:
>
> > Still having no luck logging on to the new mail platform, below is what I do.
> >
> > telnet mail.demon.co.uk 110
> > Resolving mail.demon.co.uk... trying 91.221.168.28:110
> > Telnet session 1 connected to mail.demon.co.uk
> > +OK The Microsoft Exchange POP3 service is ready.
> >
> > I type in username and get the message
> > -ERR Protocol error  19
>
> Are you just entering the username, or are you preceding it with the
> command "user"?  If not, that would explain the error 19 (which seems to
> be "unknown command").
>
> e.g. type "user administrator@yourdomain.demon.co.uk<enter>"
>
> > Type in password and get the message
> > -ERR Protocol error  19
>
> Ditto for the password: it must be preceded by the command "pass".
>
> e.g. type "pass yourpassword<enter>"
>
> Let us know if that helps, or if you're still having problems.
>
> By the way, do you have web access that will allow you to use the Email
> Management Portal?
>
> Brief GremNOS status report: non-compliant "Return-Path:" fields are now
> handled, and I've fixed the bug that stopped it putting POP3 messages in
> the specified mailbox[*], but at present you have to either (a) set up
> separate mailboxes for all your active usernames, then collect for each
> mailbox separately, or (b) leave the single "administrator" mailbox as
> the catch-all and put up with all messages being put into a single
> mailbox, regardless of the original recipient address.
>
> I'm intending to add an "auto" recipient mailbox mode, which will parse
> the "Received:" fields (or failing that, the "To:" and "Cc:" fields) to
> try to find the original recipient, so that it stands a fighting chance
> of doing the right thing if you get messages for multiple recipients in
> a single mailbox (e.g. you only have the detault administrator mailbox);
> it probably won't handle multiple recipient messages particularly well
> (unless they all have separate mailboxes), but I think it will be as
> good as can be achieved without the old *ENV feature (RIP).
>
> [*] the code worked the way I had documented it when I wrote it, but
> that wasn't how I had really intended it to work... 8-/
>

I just tried the user and pass, it let me in. Not using telnet very often, I
don't know much about the commands to use. Tried list and it showed me, I
presume the mail waiting. Any guidance would be welcome.

Thanks for all the help.

On Friday, in article <1343367560snz@nospam.demon.co.uk>
     pete@nospam.demon.co.uk wrote:

> In article <20120726.1320.929535snz@twoplaces.co.uk>
>            simon@twoplaces.co.uk "Simon Turner" writes:
> [snip]
> It's reassuring to learn that there is Life After Migration :)
> 
> I've still not been migrated -- at least I've received no notification 
> of migration, and the original 671 byte email is still not budging 
> from the punt.

Really?  It must be more than 30 days now, so it should should have
bounced and/or been silently deleted; their incompetent forgery really
did mess up the SDPS system... 8-)

> > Brief GremNOS status report: non-compliant "Return-Path:" fields are now
> > handled, and I've fixed the bug that stopped it putting POP3 messages in
> > the specified mailbox[*], but at present you have to either (a) set up
> > separate mailboxes for all your active usernames, then collect for each
> > mailbox separately, or (b) leave the single "administrator" mailbox as
> > the catch-all and put up with all messages being put into a single
> > mailbox, regardless of the original recipient address.
> 
> Probably too early to ask, but is there a new POP3 zip available yet?  

I've done new builds of the usual suspects with POP3SMTP added to their
configs; do you want a new build, or just the new pop3smtp.c and
smtpserv.c that I changed yesterday?  (ISTR you use you own modified
Lite build, BICBW.)

> And as probably the only person using "smtp queue" and delivering 
> locally, will the single "administrator" mailbox suffice?  (Of course 
> I'll discover this in due course, but just thought I'd ask as you've 
> BTDT with the code changes.)

Depends on whether you want to deliver to more than one mailbox.  Until
I've written the header-parsing stuff for automatic recipient detection,
there is no way for POP3 on the new platform to determine who the actual
recipient of a message was: so if all you have is the single default
"administrator" username, all you can do is download everything from
that username's mailbox as though it had been sent to a single local
address (which will be "administrator" by default, but can be overridden
to some other name of your choice).

At present I've got three usernames set up (the original administrator
and two others), and -- as you have to do nowadays -- am collecting
separately for each one, with each collection going to a different local
address.  Not ideal, but acceptable (especially since very little of my
Demon mail is of interest to me: < 5 per year on average).  Once I've
got auto-recipient-detection done, I may revert to just having the
administrator username.

> I think I'll disable all mailkill functionality at migration-time to 
> ensure I miss nothing.  I assume the POP3 GremNOS just issues a delete 
> for a mailkill match and logs the deletion?  If not I'll try to 
> implement something like this when the new source becomes available.

Right now, without the *ENV data, it doesn't try to validate the sender,
so mailkill doesn't work with POP3 on the new platform (but it will work
with the old SDPS platform).

When mailkill does match, it logs the rejection just as for SMTP, but it
doesn't explicitly log the POP3 deletion: it is taken as read.  That
could easily be changed, though.  (There's no separate POP3 log; just
the SMTP log.)  If you've set "pop3 bounce on" (which I do *not*
advise!), it will generate a DSN and send it to the address in the
"Return-Path:" header field.

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

On Friday, in article
     <20120727.0926.2snz@cj4386.demon.co.uk>
     colin@cj4386.demon.co.uk "colin may" wrote:

> I just tried the user and pass, it let me in. Not using telnet very often, I
> don't know much about the commands to use. Tried list and it showed me, I
> presume the mail waiting. Any guidance would be welcome.

Thank goodness for that!  I think your best bet for getting hold of your
new mail is to try my new Large build (v0.3e); I haven't written release
notes or anything yet, but in brief this has a few tweaks I've made for
my own devious purposes (most of which aren't present in the standard
builds) and a bit of minor standardisation work to the SMTP server, plus
of course the new POP3-SMTP code which grabs messages via POP3 and feeds
them into the SMTP server, as though they had been sent via SMTP.

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
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

The Large build was getting rather big with the new POP3 stuff in there,
so I removed the old (and I presume long-unused) "rlogin" and "rsh"
commands[*], which freed up enough space not just for the POP3 stuff,
but also for the extra dialler logging commands and John Washington's
HTTP grabber that have hitherto been in all builds apart from Large --
so there's a bit of extra functionality in the Large build on top of the
POP3 stuff.

Of immediate interest is the new family of "pop3smtp" commands ("pop3"
for short).  Probably the only one you'll want is "pop3 collect" (unless
you want to try leaving stuff on the server to begin with in case of
problems), but I'll describe them all anyway for completeness.  However,
an executive summary is this:

* If you want to leave messages on the server while doing tests (no
  messages will be deleted, and they will be downloaded again next time)
  (default is off), run this:
    pop3 leave on

* To collect any mail that may have found its way on to the old system,
  run this (substituting your real hostname and old POP3 password as
  appropriate):
    pop3 collect pop3.demon.co.uk host oldpass *env

* 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

* To collect mail from username "fred" on the new system and have it
  sent to local user "wilma", run this (substituting your real hostname
  and fred's new POP3 password as appropriate):
    pop3 collect mail.demon.co.uk fred@host.demon.co.uk fredpass wilma

The details follow.  Note that variable arguments are shown in angle
brackets <arg> below; the brackets should not be included in the real
commands!

Please note that you MUST NOT try using the special "*env" fourth
argument to "pop3 collect" with the new system, unless you want to run
the risk of mail being deleted unread...


pop3 collect <server> <username> <password> [<mailbox>]

	Takes 3 or 4 arguments, as above.

	Connects to <server>, logging in with username <username> and
	password <password>, and downloads all messages, feeding them in
	to the SMTP system as though they had been sent to the SMTP
	server with a recipient name of <mailbox> (if present),
	otherwise the local-part of <username> if that appears to be an
	address, or failing that "unknown".

	For those who have not been migrated yet, or who want to
	download from the old system in case anything has ended up
	there, setting <mailbox> to "*env" tells it to use the old *ENV
	command (unique to the old SDPS system) to find the real sender
	and recipient, and also whether the message is new or has
	already been downloaded.

	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 ("*" is an illegal character
	in DOS filenames, which means if *env isn't rewritten to
	something else first, the recipient will be declared invalid and
	the message will be rejected, i.e. deleted unread).


pop3 leave [on | off]

	Sets or reports the current "leave" setting.  If on, leaves
	copies of messages on the server after collecting them rather
	than deleting them; with the new platform, it has no way of
	knowing which messages have already been downloaded, so the
	messages will be downloaded again next time.  With the old SDPS
	system and *ENV, messages that have already been read are
	skipped and not downloaded again.

	Default is off.


pop3 bounce [on | off]

	Sets or reports the current "bounce" setting.  If on and a
	message is rejected on the grounds of sender or recipient
	(unlikely in the current version), sends a DSN to the address
	given in the "Return-Path:" header.

	Default is off: leave it that way!


pop3 timeout [<value>]

	Sets or reports the current "timeout" setting.  This is the POP3
	server response timeout in seconds -- if the server fails to
	respond to a command within the timeout, aborts the current
	connection.

	Default is 120 seconds (two minutes); 0 disables timeouts.


pop3 trace [<level>]

	Sets or reports the current "trace" level.  With higher levels
	of tracing, more and more of the POP3 activity (commands and
	responses etc.) is displayed on the console.

	Default is 0; highest meaningful level is 3.
     

Hope this helps; let us know how you get on!


[*] The "rsh" command never worked anyway: it was unimplemented, and
just returned 0...

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

On Friday, in article
     <20120727.1344.929633snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> On Friday, in article
>      <20120727.0926.2snz@cj4386.demon.co.uk>
>      colin@cj4386.demon.co.uk "colin may" wrote:
>
> > I just tried the user and pass, it let me in. Not using telnet very often, I
> > don't know much about the commands to use. Tried list and it showed me, I
> > presume the mail waiting. Any guidance would be welcome.
>
> Thank goodness for that!  I think your best bet for getting hold of your
> new mail is to try my new Large build (v0.3e); I haven't written release
> notes or anything yet, but in brief this has a few tweaks I've made for
> my own devious purposes (most of which aren't present in the standard
> builds) and a bit of minor standardisation work to the SMTP server, plus
> of course the new POP3-SMTP code which grabs messages via POP3 and feeds
> them into the SMTP server, as though they had been sent via SMTP.
>
> 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
> 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
>
> The Large build was getting rather big with the new POP3 stuff in there,
> so I removed the old (and I presume long-unused) "rlogin" and "rsh"
> commands[*], which freed up enough space not just for the POP3 stuff,
> but also for the extra dialler logging commands and John Washington's
> HTTP grabber that have hitherto been in all builds apart from Large --
> so there's a bit of extra functionality in the Large build on top of the
> POP3 stuff.
>
> Of immediate interest is the new family of "pop3smtp" commands ("pop3"
> for short).  Probably the only one you'll want is "pop3 collect" (unless
> you want to try leaving stuff on the server to begin with in case of
> problems), but I'll describe them all anyway for completeness.  However,
> an executive summary is this:
>
> * If you want to leave messages on the server while doing tests (no
>   messages will be deleted, and they will be downloaded again next time)
>   (default is off), run this:
>     pop3 leave on
>
> * To collect any mail that may have found its way on to the old system,
>   run this (substituting your real hostname and old POP3 password as
>   appropriate):
>     pop3 collect pop3.demon.co.uk host oldpass *env
>
> * 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
>
> * To collect mail from username "fred" on the new system and have it
>   sent to local user "wilma", run this (substituting your real hostname
>   and fred's new POP3 password as appropriate):
>     pop3 collect mail.demon.co.uk fred@host.demon.co.uk fredpass wilma
>
> The details follow.  Note that variable arguments are shown in angle
> brackets <arg> below; the brackets should not be included in the real
> commands!
>
> Please note that you MUST NOT try using the special "*env" fourth
> argument to "pop3 collect" with the new system, unless you want to run
> the risk of mail being deleted unread...
>
>
> pop3 collect <server> <username> <password> [<mailbox>]
>
>         Takes 3 or 4 arguments, as above.
>
>         Connects to <server>, logging in with username <username> and
>         password <password>, and downloads all messages, feeding them in
>         to the SMTP system as though they had been sent to the SMTP
>         server with a recipient name of <mailbox> (if present),
>         otherwise the local-part of <username> if that appears to be an
>         address, or failing that "unknown".
>
>         For those who have not been migrated yet, or who want to
>         download from the old system in case anything has ended up
>         there, setting <mailbox> to "*env" tells it to use the old *ENV
>         command (unique to the old SDPS system) to find the real sender
>         and recipient, and also whether the message is new or has
>         already been downloaded.
>
>         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 ("*" is an illegal character
>         in DOS filenames, which means if *env isn't rewritten to
>         something else first, the recipient will be declared invalid and
>         the message will be rejected, i.e. deleted unread).
>
>
> pop3 leave [on | off]
>
>         Sets or reports the current "leave" setting.  If on, leaves
>         copies of messages on the server after collecting them rather
>         than deleting them; with the new platform, it has no way of
>         knowing which messages have already been downloaded, so the
>         messages will be downloaded again next time.  With the old SDPS
>         system and *ENV, messages that have already been read are
>         skipped and not downloaded again.
>
>         Default is off.
>
>
> pop3 bounce [on | off]
>
>         Sets or reports the current "bounce" setting.  If on and a
>         message is rejected on the grounds of sender or recipient
>         (unlikely in the current version), sends a DSN to the address
>         given in the "Return-Path:" header.
>
>         Default is off: leave it that way!
>
>
> pop3 timeout [<value>]
>
>         Sets or reports the current "timeout" setting.  This is the POP3
>         server response timeout in seconds -- if the server fails to
>         respond to a command within the timeout, aborts the current
>         connection.
>
>         Default is 120 seconds (two minutes); 0 disables timeouts.
>
>
> pop3 trace [<level>]
>
>         Sets or reports the current "trace" level.  With higher levels
>         of tracing, more and more of the POP3 activity (commands and
>         responses etc.) is displayed on the console.
>
>         Default is 0; highest meaningful level is 3.
>
>
> Hope this helps; let us know how you get on!
>
>
> [*] The "rsh" command never worked anyway: it was unimplemented, and
> just returned 0...
>

High Simon,

Many thanks for your help. I'll be downloading one of the files and will let
you know how I get on.

	- hi; in article, <20120727.1344.929633snz@twoplaces.co.uk>,
	   simon@twoplaces.co.uk "Simon Turner" helpfully advised:
>	       colin@cj4386.demon.co.uk "colin may" wrote:
>>I just tried the user and pass, it let me in. Not using telnet very often,
>>I don't know much about the commands to use. Tried list and it showed me,
>>I presume the mail waiting. Any guidance would be welcome.
>
>Thank goodness for that!  I think your best bet for getting hold of your
>new mail is to try my new Large build (v0.3e); I haven't written release
>notes or anything yet, but in brief this has a few tweaks I've made for
>my own devious purposes (most of which aren't present in the standard
>builds) and a bit of minor standardisation work to the SMTP server, plus
>of course the new POP3-SMTP code which grabs messages via POP3 and feeds
>them into the SMTP server, as though they had been sent via SMTP.
>
>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).

>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?
>
>The Large build was getting rather big with the new POP3 stuff in there,
>so I removed the old (and I presume long-unused) "rlogin" and "rsh"
>commands[*], which freed up enough space not just for the POP3 stuff,
>but also for the extra dialler logging commands and John Washington's
>HTTP grabber that have hitherto been in all builds apart from Large --
>so there's a bit of extra functionality in the Large build on top of the
>POP3 stuff.

	- 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 :-)
>
>Of immediate interest is the new family of "pop3smtp" commands ("pop3"
>for short).  Probably the only one you'll want is "pop3 collect" (unless
>you want to try leaving stuff on the server to begin with in case of
>problems), but I'll describe them all anyway for completeness.  However,
>an executive summary is this:
>
>* If you want to leave messages on the server while doing tests (no
>  messages will be deleted, and they will be downloaded again next time)
>  (default is off), run this:
>    pop3 leave on
>
>* To collect any mail that may have found its way on to the old system,
>  run this (substituting your real hostname and old POP3 password as
>  appropriate):
>    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> - ?
>
>* 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.

	- 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.)
>
>* To collect mail from username "fred" on the new system and have it
>  sent to local user "wilma", run this (substituting your real hostname
>  and fred's new POP3 password as appropriate):
>    pop3 collect mail.demon.co.uk fred@host.demon.co.uk fredpass wilma
>
>The details follow.  Note that variable arguments are shown in angle
>brackets <arg> below; the brackets should not be included in the real
>commands!
>
>Please note that you MUST NOT try using the special "*env" fourth
>argument to "pop3 collect" with the new system, unless you want to run
>the risk of mail being deleted unread...
>
>
>pop3 collect <server> <username> <password> [<mailbox>]
>
>        Takes 3 or 4 arguments, as above.
>
>        Connects to <server>, logging in with username <username> and
>        password <password>, and downloads all messages, feeding them in
>        to the SMTP system as though they had been sent to the SMTP
>        server with a recipient name of <mailbox> (if present),
>        otherwise the local-part of <username> if that appears to be an
>        address, or failing that "unknown".

	- 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?
>
>        For those who have not been migrated yet, or who want to
>        download from the old system in case anything has ended up
>        there, setting <mailbox> to "*env" tells it to use the old *ENV
>        command (unique to the old SDPS system) to find the real sender
>        and recipient, and also whether the message is new or has
>        already been downloaded.
>
>        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 ("*" is an illegal character
>        in DOS filenames, which means if *env isn't rewritten to
>        something else first, the recipient will be declared invalid and
>        the message will be rejected, i.e. deleted unread).

	*nod*  thanks for the explicit warning & instruction.
>
>pop3 leave [on | off]
>
>        Sets or reports the current "leave" setting.  If on, leaves
>        copies of messages on the server after collecting them rather
>        than deleting them; with the new platform, it has no way of
>        knowing which messages have already been downloaded, so the
>        messages will be downloaded again next time.  With the old SDPS
>        system and *ENV, messages that have already been read are
>        skipped and not downloaded again.
>
>        Default is off.
>
>
>pop3 bounce [on | off]
>
>        Sets or reports the current "bounce" setting.  If on and a
>        message is rejected on the grounds of sender or recipient
>        (unlikely in the current version), sends a DSN to the address
>        given in the "Return-Path:" header.
>
>        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...)
>
>pop3 timeout [<value>]
>
>        Sets or reports the current "timeout" setting.  This is the POP3
>        server response timeout in seconds -- if the server fails to
>        respond to a command within the timeout, aborts the current
>        connection.
>
>        Default is 120 seconds (two minutes); 0 disables timeouts.
>
>
>pop3 trace [<level>]
>
>        Sets or reports the current "trace" level.  With higher levels
>        of tracing, more and more of the POP3 activity (commands and
>        responses etc.) is displayed on the console.
>
>        Default is 0; highest meaningful level is 3.
>     
>
>Hope this helps; let us know how you get on!

	- i'm hoping it does/will, too; i'll do so, as and when...
>
>[*] 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.

	- and again, thanks for your work;

	- love, ppint. (just been given my hospital date: 21/8/12)
	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
    "I for one have been eight-bit clean for at least 15 years"
 - keith f. lynch on rec.arts.sf.fandom 20/3/2010 (3/20/2010 for merkins)

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

[Following up to myself; apologies]

On Wednesday, in article
     <20120801.1206.930022snz@twoplaces.co.uk>
     simon@twoplaces.co.uk "Simon Turner" wrote:

> 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 [...]

Executive summary (for ppint, or anyone else wondering): it seems that
you *can't* move the catch-all mail away from the privileged initial
administrator account, even if you want to.

Details, for anyone who may be interested:

It appears that the initial user account that is already set up for you
is the special bit: my tests show that mail to unknown addresses always
gets sent to that account's mailbox, regardless of whether the
administrator@ address is (a) associated with it, (b) associated with
another account, or (c) not associated with anything.

This initial user account is clearly different from any others that you
might set up, because it doesn't have the checkbox to say whether it has
admin rights (it always has them), and it can't be deleted (it doesn't
have a "delete" button, even if you log in as a different
admin-privileged user, although a different admin user *can* mark it as
inactive).

Demon's Email Management Portal Guide is thus shown to be not just
confusing with regard to "administrator", but also significantly
incorrect.  No surprise there, then.

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

	- 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

On Saturday, in article
     <20120803.2333.12080043snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - hi; in article, <20120801.1206.930022snz@twoplaces.co.uk>,
>              simon@twoplaces.co.uk "Simon Turner" elaborated:
> >                        "ppint. at pplay" wrote:

> >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> ?

Nope.  Packet tracing is much lower level stuff than hop check (aka
traceroute); the packet driver interface connects to packet driver
software that is itself talking to a network card (this is what my build
uses to access DSL); and IP packet filtering is firewall-type stuff,
allowing you to apply filter rules to IP packets.  It's fairly complex,
and I don't know anyone that ever used it.

> > * RIP routing
> > * Domain name server
> 
>         - is this not "domain query <ip address>" from net> ?

Nope.  That's a local DNS *client* querying a remote (Demon) server;
only hardcore techies want to run their own local DNS servers.

> > * 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.

If there are bits missing from Lite that you want to use again, I can do
a build that re-enables them (at the expense of a larger memory
footprint)...

>         - 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?

No, it's genuine enough.  The anti-spam in the new system seems a lot
more effective than the old cloudmark stuff, plus if the spammers are
targetting bogus recipient addresses, they can all be left uncollected
in the catch-all mailbox (once you've set up other user accounts to
receive the stuff you *do* want to get).

> >(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 - ?

Quite.  Sigh.

> >Demon's documentation on the new mail system, and in particular the
> >specialness of "administrator" is, as you would expect, vague, confusing
> >and contradictory.
> >
> >[...]
> 
>         - *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.

So I see; I'll respond to it later.  (In short, don't worry too much.)

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

Interesting thought; you may be right.  I've set up a separate user
account to receive mail addressed to administrator@ and postmaster@, to
keep them away from the catch-all that will attract all the stuff to
bogus recipient addresses.

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

Not this bit, actually; I still don't know (and won't, for 30 days)
whether they silently delete uncollected mail or bounce it back.

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

Yup.

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

If "unknown" is in your FTPUSERS file, you wouldn't have suffered Pete's
fate...

> >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?

Not that I'm aware of; is this something I should correct?

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

Test message sent to weeble at i-m-t; I'll report back!

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

High Simon,

I downloaded the file lrge_03e.zip, and it works. I can now collect mail and
send. I've not tried changing the mailboxes. From what i've read on the news
groups it seems a little confusing.

Many thanks for all your help and the time you have put in working on the
problem.

	- hi; in article, <20120804.1418.930196snz@twoplaces.co.uk>,
	    simon@twoplaces.co.uk "Simon Turner" clarified [0]:
>	              "ppint. at pplay" wrote:
>>           simon@twoplaces.co.uk "Simon Turner" elaborated:
>> >                  "ppint. at pplay" wrote:
>> >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> ?
>
>Nope.  Packet tracing is much lower level stuff than hop check (aka
>traceroute); the packet driver interface connects to packet driver
>software that is itself talking to a network card (this is what my
>build uses to access DSL);

	- the packet driver interface is what'd be needed, to use a
	network card with dos driver, to use a dos desktop for broad-
	band (still my longer-term objective) ?

>and IP packet filtering is firewall-type stuff, allowing you to apply
>filter rules to IP packets.  It's fairly complex, and I don't know
>anyone that ever used it.

	- o.k.  (i think i remember people (including richard, perhaps)
	IP using packet tracing to diagnose a problem a long time ago -
	but there's no saying they were using the dos suite to do this.)
	  hop check i do use, and it's still there in 03e.
>
>> > * RIP routing
>> > * Domain name server
>> 
>>	- is this not "domain query <ip address>" from net> ?
>
>Nope.  That's a local DNS *client* querying a remote (Demon) server;
>only hardcore techies want to run their own local DNS servers.

	- lol - there's three or four people i know, i'd not put it past.
>
>> > * 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.
>
>If there are bits missing from Lite that you want to use again, I can do a
>build that re-enables them (at the expense of a larger memory footprint)...

	- many thanks: once i'm safely through this forced emigration,
	i may ask you (unless it'd be simpler for you to do a pplg_03e,
	as it were, using the work you've already done for pplt_03e); i
	have been using clockwork frog's view tsr whilst online to e.g.
	try and check a sender vs. my mailkill file, but it's not got a
	search function and it stops everything else: so if i take more
	than a few seconds, it kills the dialled-up session, and the
	phoneline drops.
>
>>	- 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?
>
>No, it's genuine enough.  The anti-spam in the new system seems a lot
>more effective than the old cloudmark stuff, plus if the spammers are
>targetting bogus recipient addresses, they can all be left uncollected
>in the catch-all mailbox (once you've set up other user accounts to
>receive the stuff you *do* want to get).

	- both good; & so using the catch-all'll be a significant relief.
[]
>> >Demon's documentation on the new mail system, and in particular the
>> >specialness of "administrator" is, as you would expect, vague, confusing
>> >and contradictory.
>> >[...]
>>[]
>
>So I see; I'll respond to it later.  (In short, don't worry too much.)

	- ta.
>
>>	- 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.
>
>Interesting thought; you may be right.  I've set up a separate user
>account to receive mail addressed to administrator@ and postmaster@, to
>keep them away from the catch-all that will attract all the stuff to
>bogus recipient addresses.

	- *nods*; but iiuc c+w've not mentioned in all of this that
	we should (rfc/use-for "should") *all* open a user a/c for
	postmaster, nor made it an existing user a/c by default - so
	the catch-all a/c default named administrator@ is the only
	a/c they can be (almost) certain we'll all have.
>
>> >>	- 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 ( :-( )
>
>Not this bit, actually; I still don't know (and won't, for 30 days)
>whether they silently delete uncollected mail or bounce it back.

	- point.  i was presuming.
>
>> >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.
>
>Yup.

>> >(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...
>
>If "unknown" is in your FTPUSERS file, you wouldn't have suffered Pete's
>fate...

	- i just bunged an extra line for it in the alias file - and'd
	not got around to removing it, when it didn't work for the c+w
	forgery.
>
>> >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?
>
>Not that I'm aware of; is this something I should correct?

	- oh yes!  (though not absolutely everything by him): one of
	sf's all-time greatest humourists, _Dimension of Miracles_
	(or the extract in a year's best anthology, "The Story of the
	Creation of the Earth") is whence douglas adams inadvertently
	stole much of the early hitch-hiker's from, ideas and details;
	_Mindswap_ is better still; _The Journey of Joenes_ (_Journey
	Beyond Tomorrow_) provides further friendly assurance of the
	insanity of the world, and _Options_ is a little like _Mindswap_
	seen from the inside...
	  _Immortality, Inc._ is an exception, being of significant
	grimth and not to all sheckley-fans' taste; it's good and well
	worth reading, but not for light relief.
	  just about all of sheckley's short stories are humorous gems,
	including the a a ace planetary investigators series (recently
	run in dramatised form on beeb r7/4extra as "The Laxian Key",
	which is the title of one of them); all of his collections are
	worth grabbing, and you see any of them - few of them've seen
	reprints after the first uk p/b editions, so they're getting
	steadily harder to find - not just _The Robert Sheckley Omnibus
	(a kind of "best of", plus _Immortality, Inc._) (penguin_) and
	the beautifully-entitled _The People Trap and Other Pitfalls,
	Snares, Devices and Delusions, as well as Two Sniggles and
	A Contrivance_...
>
>> >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.
>
>Test message sent to weeble at i-m-t; I'll report back!

	- spotted in the queueue on the punt-3 cluster before i down-
	loaded this batch of news from the firedrake; my immediate re-
	action was "i'd better add a line to the alias file, first",
	before i realised what it'd be and quashed the automatic urge.

	- again, thanks for the work you're putting in on all this;
	let me know if you'd like an eye kept open for any of the
	sheckleys - or any other fantasy &/or sf, for that matter.

	- love, ppint.

	[0] - ghee!

	[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

On Saturday, in article
     <20120804.2147.10snz@cj4386.demon.co.uk>
     colin@cj4386.demon.co.uk "colin may" wrote:

> I downloaded the file lrge_03e.zip, and it works. I can now collect mail and
> send. I've not tried changing the mailboxes. From what i've read on the news
> groups it seems a little confusing.
> 
> Many thanks for all your help and the time you have put in working on the
> problem.

Excellent; glad it's working for you, and thanks for letting us know.

Changing mailboxes is actually fairly straightforward, it's just that
the Email Management Portal Guide is a load of cobblers.  I may knock up
a more helpful set of instructions if I can find the time; in the
meantime, if you do want to rename things away from the single default
"administrator" account (which is, I presume, what you're using at the
moment), let me know.

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

In article <20120805.1159.930228snz@twoplaces.co.uk>
           simon@twoplaces.co.uk "Simon Turner" writes:

> On Saturday, in article
>      <20120804.2147.10snz@cj4386.demon.co.uk>
>      colin@cj4386.demon.co.uk "colin may" wrote:
> 
> > I downloaded the file lrge_03e.zip, and it works. I can now collect mail and
> > send. I've not tried changing the mailboxes. From what i've read on the news
> > groups it seems a little confusing.
> >
> > Many thanks for all your help and the time you have put in working on the
> > problem.

Seconded!

> Excellent; glad it's working for you, and thanks for letting us know.
> 
> Changing mailboxes is actually fairly straightforward, it's just that
> the Email Management Portal Guide is a load of cobblers.  I may knock up
> a more helpful set of instructions if I can find the time; in the
> meantime, if you do want to rename things away from the single default
> "administrator" account (which is, I presume, what you're using at the
> moment), let me know.

I too would appreciate a few notes on setting up mailboxes in the EMP 
if you can find any tuits.  I'd like to look at the portal myself but 
don't think I have access until the migration email finally arrives; 
somewhat annoying as I'd like to prepare as much as possible ahead of 
M-Day.

From what I've read here and in d.service I gather the instructions 
there are far from "production quality" (or even correct) so even a 
short list of the gotchas would be really helpful!

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  Andr� Gide

Sorry if this has been seen before, it has not turned up on any of my
machines.

Another problem has turned up In the last few hours. I telnet to
mail.demon.co.uk 110 it lets me in, but the command list does not work. Get
the message "err command not valid in this state". I went back to Gremnos 03d
nhat was working two days ago. Same problem, has anything changed?

So far pop3 command still works in Gremnos 03e.

On Sunday, in article
     <20120805.0858.12080059snz@i-m-t.demon.co.uk>
     v$af$ppint@i-m-t.demon.co.uk "ppint. at pplay" wrote:

>         - hi; in article, <20120804.1418.930196snz@twoplaces.co.uk>,
>             simon@twoplaces.co.uk "Simon Turner" clarified [0]:
> >                     "ppint. at pplay" wrote:
> >>           simon@twoplaces.co.uk "Simon Turner" elaborated:

> >...; the packet driver interface connects to packet driver
> >software that is itself talking to a network card (this is what my
> >build uses to access DSL);
> 
>         - the packet driver interface is what'd be needed, to use a
>         network card with dos driver, to use a dos desktop for broad-
>         band (still my longer-term objective) ?

Probably, yes; GremNOS does have some direct support for a handful of
network cards built-in, but it's not at all clear that you would be able
to find one of those cards.  You would probably have better luck finding
packet driver software for whatever card you do manage to find.

(Hmmm.  I've just been struck by a feeling that I've got a spare 3Com
3C509 card kicking around somewhere; I'll see if I can find it.)

> >Nope.  That's a local DNS *client* querying a remote (Demon) server;
> >only hardcore techies want to run their own local DNS servers.
> 
>         - lol - there's three or four people i know, i'd not put it past.

Oh, I know people who do run their own local DNS servers; but I can't
imagine any of them using GremNOS to do so! 8-)

> >If there are bits missing from Lite that you want to use again, I can do a
> >build that re-enables them (at the expense of a larger memory footprint)...
> 
>         - many thanks: once i'm safely through this forced emigration,
>         i may ask you (unless it'd be simpler for you to do a pplg_03e,
>         as it were, using the work you've already done for pplt_03e);

Creating a new custom build is trivial; it takes a couple of minutes.
(All I need to do is copy CONFIG.H, and possibly SMTPSCFG.H and/or
NNTPCCFG.H, to a new directory and modify them accordingly, by changing
"#undef" to "#define" or vice versa for the featuers in question.)

Would you like to me re-enable the shell stuff in ppLite (call it
ppBantam 8-) and do you a quick build you can play with?

>         have been using clockwork frog's view tsr whilst online to e.g.
>         try and check a sender vs. my mailkill file, but it's not got a
>         search function and it stops everything else:

Is this just to read the mailkill file, or to edit it as well?  If the
former, I just though I'd check you're aware that GremNOS can display
files with "more filename" (still without a search capability, but it
sounds as though the view TSR isn't much better)...

But being able to shell out, with multitasking, would probably work
better.

> >>      - 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.
> >
> >Interesting thought; you may be right.  I've set up a separate user
> >account to receive mail addressed to administrator@ and postmaster@, to
> >keep them away from the catch-all that will attract all the stuff to
> >bogus recipient addresses.
> 
>         - *nods*; but iiuc c+w've not mentioned in all of this that
>         we should (rfc/use-for "should") *all* open a user a/c for
>         postmaster, nor made it an existing user a/c by default - so
>         the catch-all a/c default named administrator@ is the only
>         a/c they can be (almost) certain we'll all have.

Indeed.  Certainly there have been lots of people in the forums saying
"what do you mean by accepting mail to postmaster? I'm so confused" or
words to that effect; they may well abandon the use of postmaster.

> >If "unknown" is in your FTPUSERS file, you wouldn't have suffered Pete's
> >fate...
> 
>         - i just bunged an extra line for it in the alias file - and'd
>         not got around to removing it, when it didn't work for the c+w
>         forgery.

It might be worth leaving it in there, to ensure you still get your mail
if you accidentally misconfigure your "pop3 collect" command (or, once
the auto-recipient-detection code is finished, if it is unable to work
out who the recipient was).

I don't know about the rest of you, but a quick grep of the logs shows
that I've never received any mail to unknown@.  (Except from me, when I
was testing the POP3 collection code!)

> >> >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?
> >
> >Not that I'm aware of; is this something I should correct?
> 
>         - oh yes!  (though not absolutely everything by him): one of
>         sf's all-time greatest humourists, [...]

Oooh, he sounds worth hunting down.  Thanks!

> >> >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.
> >
> >Test message sent to weeble at i-m-t; I'll report back!
> 
>         - spotted in the queueue on the punt-3 cluster before i down-
>         loaded this batch of news from the firedrake; my immediate re-
>         action was "i'd better add a line to the alias file, first",
>         before i realised what it'd be and quashed the automatic urge.

It did, indeed, generate a DSN that was sent back to me.  (Actually,
there were two: I sent another message to myself and weeble at i-m-t
when I was testing how the current system handles mail that is Bcc'ed to
two different Demon customers in the same SMTP transaction[*].)

>         - again, thanks for the work you're putting in on all this;

A pleasure.

>         let me know if you'd like an eye kept open for any of the
>         sheckleys - or any other fantasy &/or sf, for that matter.

Thanks -- I'll have a quick rummage around here, but may well take you
up on the offer!

>         [0] - ghee!

ROFL!


[*] I was wondering whether mailing-list operators with multiple Demonic
subscribers send them individual messages or a single one with several
different recipients at different hostnames, and if you can use the
"Received:" header fields to find out.  The answer is that you can use
said fields: if there is only one recipient at your hostname, but the
first (i.e. last, reading top-to-bottom) Demon-created "Received:" field
doesn't contain "... for user@yourhost.dcu", then it was sent to
multiple Demon customers in a single SMTP transaction.

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

On Monday, in article <1344232029snz@nospam.demon.co.uk>
     pete@nospam.demon.co.uk wrote:

> In article <20120805.1159.930228snz@twoplaces.co.uk>
>            simon@twoplaces.co.uk "Simon Turner" writes:
> 
> > Changing mailboxes is actually fairly straightforward, it's just that
> > the Email Management Portal Guide is a load of cobblers.  I may knock up
> > a more helpful set of instructions if I can find the time; in the
> > meantime, if you do want to rename things away from the single default
> > "administrator" account (which is, I presume, what you're using at the
> > moment), let me know.
> 
> I too would appreciate a few notes on setting up mailboxes in the EMP 
> if you can find any tuits.

I'll try to knock something up in the next few days; I suspect it will
take me less time to write my own user guide than to document all the
errors in the official one!  (I may even try to use some up-to-date
screenshots to illustrate things. 8-)

> I'd like to look at the portal myself but 
> don't think I have access until the migration email finally arrives; 
> somewhat annoying as I'd like to prepare as much as possible ahead of 
> M-Day.

Open offer to non-migrated dispc denizens:

If you want to see (some of) what the Portal is like, as well as have
the opportunity to receive mail via the new system so you can check
connectivity etc., I'd be happy to create a (non-admin) user account at
ashes.dcu for any dispc denizen that would like one.

You would get your own user account with a primary e-mail address and
unique password (which are used to log in to both the POP3 server and
the EMP); without admin privileges all you can do when logged in to the
EMP is edit your own account settings (change your full name; add and/or
delete additional non-primary addresses; change which address is the
primary one; change your password; change your security questions),
which isn't all that exciting, but (a) you would get a flavour of how
the Portal works, (b) you could test whether your browser works with the
Portal, and (c) you could experiment with sending mail to your ashes.dcu
address(es) and retrieving it via POP3 to see how it deals with
(non-catch-all) mail.

If you'd like an account, send me an e-mail and I'll create one, getting
the system to send you a confirmation message that will include your
password.  Changes take about 70 minutes to take effect, so leave it a
couple of hours before playing with it.  (The system won't let you add
an address that's already in use, so you needn't worry about treading on
any toes.)

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