Thread: archives' email-address obscurifier should not trigger on URLs

An example of $subject can be seen here:
http://archives.postgresql.org/pgsql-bugs/2009-05/msg00141.php
I believe this is probably the same issue that KevinField was reporting
here:http://archives.postgresql.org/message-id/200904171407(dot)n3HE7uri070869(at)wwwmaster(dot)postgresql(dot)org(dot)For
info,0xC0000005 is a pretty general access violation error.
 

This turns what should be an easy link-click into a bit of a pain.
If people get more enthusiastic about referencing the archives by
message-ID it's going to become a real issue.  Can we tighten that up?

I realize that message IDs are hard to tell from email addresses in
general, but if it's part of a URL I think we can assume it doesn't need
to be obscured.
        regards, tom lane

Tom Lane wrote:
> An example of $subject can be seen here:
> http://archives.postgresql.org/pgsql-bugs/2009-05/msg00141.php
> 
>     I believe this is probably the same issue that Kevin
>     Field was reporting here:
>
http://archives.postgresql.org/message-id/200904171407(dot)n3HE7uri070869(at)wwwmaster(dot)postgresql(dot)org(dot)
>     For info, 0xC0000005 is a pretty general access violation error.
> 
> This turns what should be an easy link-click into a bit of a pain.
> If people get more enthusiastic about referencing the archives by
> message-ID it's going to become a real issue.  Can we tighten that up?
> 
> I realize that message IDs are hard to tell from email addresses in
> general, but if it's part of a URL I think we can assume it doesn't need
> to be obscured.

Hmm.  I have worked around this by refusing to munge email addresses if
they contain a /.  I've reran the archiver over pgsql-bugs for this
month, so this particular message looks fine now.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Hmm.  I have worked around this by refusing to munge email addresses if
> they contain a /.  I've reran the archiver over pgsql-bugs for this
> month, so this particular message looks fine now.

Thanks, that definitely works better.  The / dependency is a bit of a
kluge but it seems unlikely to break in any reasonable cases.
        regards, tom lane