MHonArc - Bugs: bug #18112, <SPAMMODE> produces broken...
You are not allowed to post comments on this tracker with your current authentication level.
bug #18112: <SPAMMODE> produces broken links
Submitter: | Jeff Breidenbach <jab> | ||
Submitted: | Thu 26 Oct 2006 05:22:13 AM UTC | ||
Category: | MIME Filter | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | Undesired Behavior |
Status: | Wont Fix | Privacy: | Public |
Assigned to: | None | Open/Closed: | Closed |
Operating System: | Linux | Perl Version: | 5.6.8 |
Component Version: | 2.6.16 | Fixed Release: | N/A |
Sun 02 Jan 2011 08:57:49 AM UTC, comment #5: |
Earl Hood <ehood> |
Mon 04 May 2009 03:26:24 AM UTC, comment #4: For the comment #3 URL, is the "breaking" the
|
Earl Hood <ehood> |
Mon 04 May 2009 12:56:58 AM UTC, comment #3: Note to self - here's a particularly strong example. Might be breaking for two separate reasons.
|
Jeff Breidenbach <jab> |
Mon 30 Jul 2007 02:53:17 AM UTC, comment #2: The work around for this is - for us - is to detect and kill off this type of broken at serving time. So not so critical from my perspective. |
Jeff Breidenbach <jab> |
Tue 01 May 2007 03:39:12 PM UTC, comment #1: This is a limitation of SPAMMODE, and the related resources
|
Earl Hood <ehood> |
Thu 26 Oct 2006 05:22:13 AM UTC, original submission:
When an address is obfuscated due to spam mode, it is not uncommon to create a broken hyperlink. I think it is better to not create a hyperlink at all than to create a broken one. Examples:
|
Jeff Breidenbach <jab> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-01-02 | ehood | Category | None | MIME Filter | |
Item Group | None | Undesired Behavior | |||
Status | None | Wont Fix | |||
Open/Closed | Open | Closed | |||
Fixed Release | N/A |
Powered by Savane 3.13-3230.
Corresponding source code
For mail-archive.com, the following can be used so addresses
inside a URL is not modified. This could be generalized
to handle other contextual scenarious as desired.
I'm going to mark this item a "Wont Fix" since I see
no practical solution with existing mhonarc resources,
and the technique mentioned below can be used to get
desired results.
--------------------------------------------------------------
This method utilizes mhasiteinit.pl:
http://www.mhonarc.org/MHonArc/doc/install.html#sitelib
You need to make sure MODIFYBODYADDRESSES is disabled. If
you have a master resource file, you can add the following
at the end to ensure this:
<NOMODIFYBODYADDRESSES>
Or use the -nomodifybodyaddresses command-line option.
Then, you can have a mhasiteinit.pl like the following:
# START of mhasiteinit.pl
#------------------------
## Set package to something other than "mhonarc" to protect ourselves
## from unintentionally screwing with MHonArc's internals
package mhonarc_site_init;
## Mail-archive.com text pre-filter to not munge m-a links.
## IMPORTANT: Make sure MODIFYBODYADDRESSESS is NOT enabled since
## we obscure the addresses here. If set, our function
## will not get called.
$readmail::TextPreFilter = sub {
my $fields = shift;
my $data_r = shift;
# do not rewrite cid: URLs.
$$data_r =~ s{
((?:cid:)?|(?:(?:http://(?:www\.)?)?mail-archive\.com/)?)($mhonarc::AddrExp)
}{
($1 eq "") ? mhonarc::rewrite_raw_address($2) : $1.$2;
}gieox;
};
##---------------------------------------------------------------------------##
## Make sure to return a true value for require().
##---------------------------------------------------------------------------##
1;
_END_