You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Kent Oyer <ke...@mxguardian.net> on 2025/01/27 20:17:41 UTC
Re[2]: Close bugs
Thank you. Here's a couple more that I've worked on but am unable to close:
60438267
On Mon, Jan 27, 2025 at 01:10 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
------------------------------------------------------------------------------------------------------------------
CAUTION: External email from: sa-bugz-20080315@billmail.scconsult.com
Use caution before clicking on links or opening attachments.
------------------------------------------------------------------------------------------------------------------
On 2025-01-27 at 13:28:15 UTC-0500 (Mon, 27 Jan 2025 18:28:15 +0000)
Kent Oyer <kent@mxguardian.net (mailto:kent@mxguardian.net)>
is rumored to have said:
The following bugs can be marked CLOSED FIXED
8262
8300
8304
Thanks
Kent
Done.
--
Bill Cole
Re[2]: Close bugs
Posted by Kent Oyer <ke...@mxguardian.net>.
I see what you are saying. My understanding was they just wanted the flag to be available so that other plugins could use it. I'm not sure if adjusting scores is a good idea or not.
Thank you
On Mon, Jan 27, 2025 at 04:33 PM, Bill Cole <sa...@billmail.scconsult.com> wrote:
------------------------------------------------------------------------------------------------------------------
CAUTION: External email from: sa-bugz-20080315@billmail.scconsult.com
Use caution before clicking on links or opening attachments.
------------------------------------------------------------------------------------------------------------------
On 2025-01-27 at 16:29:29 UTC-0500 (Mon, 27 Jan 2025 21:29:29 +0000)
Kent Oyer <kent@mxguardian.net (mailto:kent@mxguardian.net)>
is rumored to have said:
Here's a couple more that I've worked on but am unable to close:
6043
I don't see a resolution there. Does the cited issue no longer occur
in 4.x?
Yes I believe that is the case. The question is from 15 years ago and
the OP was asking how to determine if a URI came from a link or if it
was parsed from text (i.e. "non-linkified"). The solution is to check
the link type:
if ( $info->{'types'}->{'a'} ) { # this URI came from a clickable
link } if ( $info->{'types'}->{'parsed'} ) { # this URI was parsed
from text }
The specific ask of the bug has been fulfilled: get_uri_detail() returns
the fact that a URI is "unlinked" (not in a form that a MUA is likely to
linkify) and/or "parsed" (URL in the body text, not in a HTML tag)
and/or "schemeless" (such as an email address in body text) so a plugin
*could* use that.
It seemed to me that it was also a request to make it possible for
URIBL* rules to adjust scores based on the provenance of the "URI" which
I don't believe is possible without a substantial amount of new code &
documentation.
I've closed it with a bit of discussion. I don't think the high-level
problem has been entirely resolved (filenames being checked as URI
domains causing FPs) but I'm not sure that is a big enough problem to
demand a fix.
--
Bill Cole
bill@scconsult.com (mailto:bill@scconsult.com) or billcole@apache.org (mailto:billcole@apache.org)
(AKA @grumpybozo@toad.social (mailto:grumpybozo@toad.social) and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire
Re: Close bugs
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2025-01-27 at 16:29:29 UTC-0500 (Mon, 27 Jan 2025 21:29:29 +0000)
Kent Oyer <ke...@mxguardian.net>
is rumored to have said:
>>> Here's a couple more that I've worked on but am unable to close:
>>> 6043
>>
>> I don't see a resolution there. Does the cited issue no longer occur
>> in 4.x?
> Yes I believe that is the case. The question is from 15 years ago and
> the OP was asking how to determine if a URI came from a link or if it
> was parsed from text (i.e. "non-linkified"). The solution is to check
> the link type:
> if ( $info->{'types'}->{'a'} ) { # this URI came from a clickable
> link } if ( $info->{'types'}->{'parsed'} ) { # this URI was parsed
> from text }
The specific ask of the bug has been fulfilled: get_uri_detail() returns
the fact that a URI is "unlinked" (not in a form that a MUA is likely to
linkify) and/or "parsed" (URL in the body text, not in a HTML tag)
and/or "schemeless" (such as an email address in body text) so a plugin
*could* use that.
It seemed to me that it was also a request to make it possible for
URIBL* rules to adjust scores based on the provenance of the "URI" which
I don't believe is possible without a substantial amount of new code &
documentation.
I've closed it with a bit of discussion. I don't think the high-level
problem has been entirely resolved (filenames being checked as URI
domains causing FPs) but I'm not sure that is a big enough problem to
demand a fix.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire
Re[2]: Close bugs
Posted by Kent Oyer <ke...@mxguardian.net>.
Here's a couple more that I've worked on but am unable to close:
6043
I don't see a resolution there. Does the cited issue no longer occur in 4.x?
Yes I believe that is the case. The question is from 15 years ago and the OP was asking how to determine if a URI came from a link or if it was parsed from text (i.e. "non-linkified"). The solution is to check the link type:
if ( $info->{'types'}->{'a'} ) { # this URI came from a clickable link } if ( $info->{'types'}->{'parsed'} ) { # this URI was parsed from text }
Re: Close bugs
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2025-01-27 at 15:17:41 UTC-0500 (Mon, 27 Jan 2025 20:17:41 +0000)
Kent Oyer <ke...@mxguardian.net>
is rumored to have said:
> Here's a couple more that I've worked on but am unable to close:
> 6043
I don't see a resolution there. Does the cited issue no longer occur in 4.x?
> 8267
Closed.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire