🚀 go-pugleaf

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

> You will also need to set the wildcard pattern with the new "pop3
> wildpat" command; [...]
> 
>   pop3 wildpat ">Received: from *[      ]by *.inty.net *[       ]for <**>*"
> 
> The stuff in the two pairs of square brackets [ ] is a space (ASCII 32)
> and a tab (ASCII 9)

Pete has just pointed out to me that you can use \t in place of the tab
character -- I'd forgotten that quoted strings in commands get properly
parsed.  So you can instead use this rather nicer command, which gives
the same pattern once GremNOS has processed it:

  pop3 wildpat ">Received: from *[ \t]by *.inty.net *[ \t]for <**>*"

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

	- hi; in article, <20120905.1309.932310snz@twoplaces.co.uk>,
	  simon@twoplaces.co.uk "Simon Turner" reflected & updated:

>I've just finished testing and uploaded binaries for GremNOS v0.3f (with
>luck, just in time for ppint, who was migrated just over an hour ago).

	- thanks for the thought: alas, i didn't connect to download
	news between 08:00 and 18:00 bst, so my first (couple of)
	POP3 mail dow^W collections were using pplt_03e (which worked
	fine, though not quite as i expected in a couple of ways, one
	of which could easily've been my failure to double-check the
	instruction sheet for full comprehension...)(t'other was that
	"leave on" after collection proved to be the default, which i
	didn't discover 'til the second time i connected & collected:
	but this wasn't pplt_03e's fault, and was fixed on the follow-
	ing connection by a guessed-at command, pop3 leave off<enter>
	from the net> prompt.)(well, it _seems_ to've worked...)
>
>v0.3f adds two significant improvements to the POP3 side of things
>compared to the previous v0.3e:
>
>(a) There's a new wildcard-based system that, if used, causes GremNOS to
>    download the message header via POP3 and parse it to find the sender
>    and recipient (effectively replacing the functionality that used to
>    be available with Demon's *ENV POP3 extension) -- it's nothing like
>    as efficient as *ENV, because it has to download and inspect the
>    entire header rather than just read a short (five line) response,
>    but it does work.  I hope it won't be unacceptably slow for those
>    using a modem!
>
>(b) If the sender isn't known (because you haven't used the *ENV or
>    wildcard systems to find it) and you have a non-empty MAILKILL file,
>    the message header can (optionally) be downloaded and parsed to find
>    the sender, ready to check against your mailkill rules: if this is
>    not done, mailkill checking doesn't happen at all.
>
>I've also improved the handling of unusual mailbox names to make it less
>likely that messages will be rejected because of invalid filename chars.
[snip - not so far tested by yr hmbl srppint.]
>
>As with 0.3e, the following new builds can by downloaded from my
>ashes.org.uk web site (there's no index page, just files) -- the full
>set of builds is available this time:
>
>http://www.ashes.org.uk/gremnos/pplt_03f.zip    ppint's custom Lite build

	- allowing ppint.s (and others) unfortunate enough to receive
	large amounts of ub/ce to apply mailkill file rules to mail
	addressed to postmaster@, and even close this address to mail;
	if you disable it, do *not* forget to re-enable it afterwards -
	as i did.  once.
>
>Wildcard header scanning
>------------------------
>
>The wildcard system in (a) above is used if the fourth argument to the
>"pop3 collect" command is "*wild" (cf. the old "*env" argument), e.g.
>
>  pop3 collect mail.demon.co.uk administrator@host.demon.co.uk pass *wild
>
>You will also need to set the wildcard pattern with the new "pop3
>wildpat" command; there is no default pattern hard-wired in, because it
>would be very specific to the current state of Demon's new platform and
>might stop working in the future.  For the new Demon mail platform, it
>should currently be set thus (put it in your AUTOEXEC.NET):
>
>  pop3 wildpat ">Received: from *[      ]by *.inty.net *[       ]for <**>*"

	- this wildcard system appears to work fine; i placed the above
	line just before the PPP commands section, & after the NNTP com-
	mands, but suspect this isn't critical, since a) it'll only be
	triggered after the connection is established, and b) simon'd've
	warned if it were - unless he's possessed of a sense of humour
	most perfectly suited to the denizens of afp or alt.sex.reptiles...
>
>The stuff in the two pairs of square brackets [ ] is a space (ASCII 32)
>and a tab (ASCII 9) -- check this carefully if you cut-and-paste the
>line from this article, because if you don't have the tab character in
>there, the pattern won't match the header fields created by the new
>platform.  (The space is belt-and-braces, in case they decide to stop
>using tabs and revert to the spaces that every other server uses.)

	- what happens if they decide to insert comments?  (- [a])
>
>A quick explanation of the unusual bits of this wildcard pattern:
>
> * The ">" at the beginning tells it to use the *last* match found
>   rather than the first; when using the catch-all administrator
>   mailbox, all the "Received:" fields except the last contain
>   administrator@yourhost which isn't a lot of help.  (Turnpike falls
>   foul of this.)
>
> * The unusual "**" near the end tells GremNOS which part of the pattern
>   contains the actual address it's trying to find.

	- how long would it take me to learn the hows & whys of how
	& why the above makes sense?  & is it o.k. if i just *gulp*,
	and say "yes, simon, certainly, simon"/"of course, simon" ?
>
>Mailkill header scanning
>------------------------
>
>As noted in (b) above, if you have a MAILKILL file but the sender
>address is unknown at the point where mailkill rules are checked,
>e.g. because you haven't used *env (on the old platform) or *wild (on
>the new one), it can download the header via POP3 and scan it for the
>"Return-Path:" header field -- if this isn't done, the mailkill rules
>are not checked at all and the sender is regarded as approved.
>
>Whether this header downloading and scanning takes place is controlled
>by the "pop3 findsender" value (0, 1 or 2):
>
>  0  Never do it: unknown senders are approved
>
>  1  Only do it if you have a non-empty MAILKILL file
>
>  2  Always do it (which means that the sender address will appear in the
>     log files if the message is rejected due to an unknown recipient
>     address, for example).
>
>The default is "pop3 findsender 1".
>
>I think that's all the important stuff: I've been running an earlier
>version of the wildcard scanning for a few weeks, and have had no
>problems, so I'm pretty confident that it all works as it should.
>
>I'll upload the source files and proper release notes when I get a
>moment.  In the meantime, please try it out and let me know if you have
>any questions, problems etc.

	- it seems to work just fine; many thanks for your very timely
	work on this.

	- love, ppint.

	[a] - sorry; please feel free to ignore this

	[drop the "v", and change the "f" to a "g", to email or cc.]
-- 
                   "The Dinner was loose again."
           - _Chanur's Homecoming_, C. J. Cherryh, 1987
                  Phantasia, Daw & Methuen Books

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

>         - hi; in article, <20120905.1309.932310snz@twoplaces.co.uk>,
>           simon@twoplaces.co.uk "Simon Turner" reflected & updated:
> 
> >[...].  For the new Demon mail platform, it
> >should currently be set thus (put it in your AUTOEXEC.NET):
> >
> >  pop3 wildpat ">Received: from *[      ]by *.inty.net *[       ]for <**>*"
> 
>         - this wildcard system appears to work fine; i placed the above
>         line just before the PPP commands section, & after the NNTP com-
>         mands, but suspect this isn't critical, since a) it'll only be
>         triggered after the connection is established, and b) simon'd've
>         warned if it were - unless he's possessed of a sense of humour
>         most perfectly suited to the denizens of afp or alt.sex.reptiles...

8-)  As you found, since this is a POP3 setup command, it can go
wherever you like, as its settings won't be looked at until the first
time you issue "pop3 collect".

(And it can be redefined whenever you like, in case you ever find
yourself having to collect POP3 mail from more than one account where
they indicate the recipient in different ways: you could have a series
of script files, each one containing "pop3 wildpat" followed by "pop3
collect", and "source" each script in turn.)

>         [...](t'other was that
>         "leave on" after collection proved to be the default, which i
>         didn't discover 'til the second time i connected & collected:
>         but this wasn't pplt_03e's fault, and was fixed on the follow-
>         ing connection by a guessed-at command, pop3 leave off<enter>
>         from the net> prompt.)(well, it _seems_ to've worked...)

This puzzles me mightily, as "pop3 leave" has always defaulted to off;
unless you've got something somewhere that turns it on, you shouldn't
need to explicitly turn it off.  Let me know if it recurs!

> >The stuff in the two pairs of square brackets [ ] is a space (ASCII 32)
> >and a tab (ASCII 9) -- check this carefully if you cut-and-paste the
> >line from this article, because if you don't have the tab character in
> >there, the pattern won't match the header fields created by the new
> >platform.  (The space is belt-and-braces, in case they decide to stop
> >using tabs and revert to the spaces that every other server uses.)
> 
>         - what happens if they decide to insert comments?  (- [a])

[a] noted; but taking it seriously, theoretically they could, although I
doubt anyone would be so silly.  But so long as the comments didn't
appear in between "by" and "*.inty.net", or between "for" and the
recipient address -- which, if they did, would break every parser on the
planet -- the existing pattern would continue to work; and if it did
stop working, it would be a simple matter to adjust it for the new
circumstances.

> >A quick explanation of the unusual bits of this wildcard pattern:
> >
> > * The ">" at the beginning tells it to use the *last* match found
> >   rather than the first; when using the catch-all administrator
> >   mailbox, all the "Received:" fields except the last contain
> >   administrator@yourhost which isn't a lot of help.  (Turnpike falls
> >   foul of this.)
> >
> > * The unusual "**" near the end tells GremNOS which part of the pattern
> >   contains the actual address it's trying to find.
> 
>         - how long would it take me to learn the hows & whys of how
>         & why the above makes sense?  & is it o.k. if i just *gulp*,
>         and say "yes, simon, certainly, simon"/"of course, simon" ?

The latter option is probably the best course!  They are both wildly
non-standard extensions to wildcard matching, invented by me just for
this purpose, and will not work outside GremNOS.

For the curious: with Demon's inserted "Received:" fields all looking
the same, with only the last one reliably containing the actual
recipient address rather than "... for <administrator@yourhost>", I
needed a mechanism to indicate that the pattern should continue to be
used even after a match had been found (normally it will stop searching
after finding a match).  No header fields start with ">", so I chose
that.

The "**" is because the pattern will generally (as in this case) contain
more than one "*" (matching an arbitrary length of any text), and I
needed something to tell GremNOS which one was the important one!  "**"
is meaningless in wildcard matching, so I chose that.  (It *should*
probably be harmless if it ever got used as part of a "live" pattern.)

GremNOS internally parses and rewrites the provided pattern into a
normal one (removing the ">" and rewriting "**" to "*", once it has
counted which instance of "*" it is) at the start of "pop3 collect".

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