Hi,
Seems like people no longer bother thinking of any alternative, innocent
reasons, but rather blame ignorance. :)
This is just an API string encoding bug in the login handler, the
validators at both ends (client-side and the server) do contain '+' in the
list of allowed characters. I'm quite intimately familiar with the
contents of some of the relevant RFCs.
The login with '
site+a...@jewski.co' got rejected with this error:
login failed email 'site
apr...@jewski.co' (bad email)
i.e. the + got mangled to a space when it's passed from the client to the
backend, and *then* it isn't valid any more. Silly encoding bug. I'll try
to get that fixed soon, can probably fix it on the server side without
releasing a new client.
On Fri, 4 Dec 2015, Rick Gilligan wrote:
> I have the same problem with my preferred email address, which also contains a "+" character.
>
> It seems no one bothers to read the RFC and actually make their email address format validation compliant with it.
>
> --
> 73
>
> Rick
>
> On Fri, Dec 4, 2015 at 8:29 AM, 'David Andrzejewski' via
aprs.fi <
apr...@googlegroups.com> wrote:
> My registered email on APRS.fi is site+aprs.fi@(domain). + is absolutely a valid character in an email address.
>
> However this does not work in the iOS app:
>
- Hessu