Hi Russell,
I have committed changes upstream that should resolve both of the problems
that you reported. The changes are a much more extensive than I expected.
Mainly due to a mixture of necessary and arguably non-essential clean-ups.
Thus a backport to 1.18 seems tricky. And 1.17 worse. So I'd r
On Sat, Feb 06, 2010 at 11:32:22AM +1100, Russell Coker wrote:
> On Sat, 6 Feb 2010, Simon Horman wrote:
> > POP3 capabilities can include spaces. Or more specifically
> > the capability may be followed by a space-delimited list of
> > parameters. So rather than use a space to delimit capabilities
On Sat, 6 Feb 2010, Simon Horman wrote:
> POP3 capabilities can include spaces. Or more specifically
> the capability may be followed by a space-delimited list of
> parameters. So rather than use a space to delimit capabilities,
> two spaces is used.
>
> So ---pop_capability "USER UIDL" works as
On Fri, Jan 08, 2010 at 07:10:07PM +1100, Simon Horman wrote:
> On Fri, Jan 08, 2010 at 03:18:05PM +1100, Russell Coker wrote:
> > Package: perdition
> > Version: 1.18-2.1
> > Severity: normal
> >
> > The list of valid capabilities differs between POP and IMAP, so it doesn't
> > make
> > sense to
On Fri, Jan 08, 2010 at 03:18:05PM +1100, Russell Coker wrote:
> Package: perdition
> Version: 1.18-2.1
> Severity: normal
>
> The list of valid capabilities differs between POP and IMAP, so it doesn't
> make
> sense to use the same config option for them.
Good thinking. It should be pretty stra
Package: perdition
Version: 1.18-2.1
Severity: normal
The list of valid capabilities differs between POP and IMAP, so it doesn't make
sense to use the same config option for them.
Also the POP capability result returns all results on one line, which according
to a brief skim read of the RFC appea
6 matches
Mail list logo
