Gurusamy Sarathy:
> Thanks Wietse, the extra check is a good idea indeed. I haven't
> tried your patch yet, but shouldn't valid_ipv6_hostaddr(host, ...)
> in your patch read valid_ipv6_hostaddr(*host, ...) instead?
> Otherwise it would seem we're passing char** where char* is
> expected. Hope I'm not misreading the patch.
Indeed. I added the syntax check after verifying that Postfix
now delivers user@[ipv6:addr] properly.
I hate it when programs silently accept bogus input such as
IPV6: prepended to a hostname or IPv4 address.
Wietse
>
> ________________________________________
> From: Wietse Venema [[email protected]]
> Sent: Friday, February 25, 2011 8:01 AM
> To: Gurusamy Sarathy
> Cc: [email protected]
> Subject: Re: IPv6 address literal issue in 'smtp'
>
> Gurusamy Sarathy:
> > Hi,
> >
> > I've run into an issue with the IPv6 support in postfix when it is
> > set up to deliver to a literal IPv6 address in the transport table.
> > It looks like 'smtpd' will only accept IPv6 address literals in RFC
> > 2821 format while 'smtp' will only accept IPv6 address literals in
> > the unadorned form (without the ipv6: prefix).
>
> Aha. This has been broken since IPv6 support was added to Postfix.
>
> Thanks for reporting this here. Unfortunately I don't have the time
> to scrape every blog on the web for Postfix problem reports.
>
> The patch below provides a workaround. I have followed your approach
> to do minimal damage, and have added a simple sanity check so that
> Postfix won't accept forms with [ipv6:hostname] or [ipv6:127.0.0.1].
>
> If some site has omitted the ipv6: prefix in some transport map or
> config file, then this patch won't break backwards compatibility.
> In the final fix, Postfix should issue a warning that the form
> [ipv6addr] is not supported, and that it will become a fatal error.
>
> The final fix would require structural change, but that is allowed
> only in the development release. Stable releases are sacred.
>
> Wietse
>
