Thread: Overeager spam fighting for link?
I came across this page today:
Subject: Re: redacting password in SQL statement in server log
The spam filtering[1] that occurs for the header information appears to have been applied to the bottom link as well - making it 404. Not sure where that is getting applied, but doing a "raw source" and checking my original inbox seems to indicate the link at the bottom of the email was sent unobscured.
[1] In which alice@gmail.com becomes alice(at)gmail(dot)com
Cheers,
Greg
On Tue, Feb 18, 2025 at 09:27:32AM -0500, Greg Sabino Mullane wrote: > I came across this page today: > > Subject: Re: redacting password in SQL statement in server log > > https://www.postgresql.org/message-id/20220724114449.qqjbwgmpcgn66yhy%40jrouhaud > > The spam filtering[1] that occurs for the header information appears to > have been applied to the bottom link as well - making it 404. Not sure > where that is getting applied, but doing a "raw source" and checking my > original inbox seems to indicate the link at the bottom of the email was > sent unobscured. FWIW I confirm that I did send a valid / unobscured link. I may be wrong but I think that this issue happened (and was solved) a few years ago.
Julien Rouhaud <rjuju123@gmail.com> writes:
>> The spam filtering[1] that occurs for the header information appears to
>> have been applied to the bottom link as well - making it 404. Not sure
>> where that is getting applied, but doing a "raw source" and checking my
>> original inbox seems to indicate the link at the bottom of the email was
>> sent unobscured.
> FWIW I confirm that I did send a valid / unobscured link.
IME the trick to keeping this from happening is to manually convert
any "@" characters in the URL you send to "%40". Usually if you
copy-and-paste from your browser address bar that happens for free.
regards, tom lane
On Tue, Feb 18, 2025 at 07:51:01PM -0500, Tom Lane wrote: > Julien Rouhaud <rjuju123@gmail.com> writes: > >> The spam filtering[1] that occurs for the header information appears to > >> have been applied to the bottom link as well - making it 404. Not sure > >> where that is getting applied, but doing a "raw source" and checking my > >> original inbox seems to indicate the link at the bottom of the email was > >> sent unobscured. > > > FWIW I confirm that I did send a valid / unobscured link. > > IME the trick to keeping this from happening is to manually convert > any "@" characters in the URL you send to "%40". Usually if you > copy-and-paste from your browser address bar that happens for free. That's what I usually do. I guess that time I just copied the link from some email header.
Yes, but surely our script can be taught that \bhttps://\S* should be excluded from the munging?
Secondarily, maybe make the web server smart enough to undo and redirect the (and) (at) stuff that would otherwise be 404?
Cheers,
Greg
On Tue, Feb 18, 2025 at 3:28 PM Greg Sabino Mullane <htamfids@gmail.com> wrote:
I came across this page today:Subject: Re: redacting password in SQL statement in server logThe spam filtering[1] that occurs for the header information appears to have been applied to the bottom link as well - making it 404. Not sure where that is getting applied, but doing a "raw source" and checking my original inbox seems to indicate the link at the bottom of the email was sent unobscured.[1] In which alice@gmail.com becomes alice(at)gmail(dot)com
The regexp used is this:
_re_mail = re.compile(r'(/m(essage-id)?/)?[^()<>@,;:\/\s"\'&|]+@[^()<>@,;:\/\s"\'&|]+')
The comment indicates it's trying to special case these links already, but clearly it's failing. I think maybe because it's not considering the /flat/ part of the URL. I haven't got time to test it out properly right this moment, but I think that might be it.