bugMHonArc - Bugs: bug #11759, email address exposed in subject...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #11759: email address exposed in subject line

Submitter:  Jeff Breidenbach <jab>
Submitted:  Fri 28 Jan 2005 07:29:05 AM UTC
   
 
Category:  Resource Variables Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Undesired Behavior
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  All Perl Version:  All
Component Version:  2.6.10 Fixed Release:  2.6.14

Thu 20 Apr 2006 04:22:43 AM UTC, comment #4: 

I sent a private email follow-up about Sympa.  I believe
facilities exist to satisfy Sympa's requirements w/o changes
to mhonarc.  If not, a support request can be submitted versus
reopening this bug.

Earl Hood <ehood>
Group administrator
Mon 10 Apr 2006 08:39:44 AM UTC, comment #3: 

MHonArc is used as the mail archives manager within Sympa mailing list software (http://www.sympa.org). The HTML files generated by MHonArc are actually HTML templates (using TT2). One reason for using templates is that some features are accessible to logged in users only suche as "removing my mail from the archives" ; therefore we need to compare the current users email address and the email address of the author of the message. We use MHonArc's $FROMADDR$ variable to achieve this goal.

Until mhonarc 2.6.13, the $FROMADDR$ variable, used within the SUBJECTHEADER resource was the original email address, not modified (against spam). We now get the spam-protected version of the email address that completely breaks our templates and Sympa's web archives.

We would need to either keep the previous behavior OR to have an $ORIGINAL_FROMADDR$ variable available, so we can use it for our templates mechanism.

If you need further informations, please contact us.

Olivier Salaün <osalaun>
Fri 08 Jul 2005 05:28:52 AM UTC, comment #2: 

Modified conversion of HTML header and handling of
$SUBJECT$ and $MSGHFIELD$.  For message header conversion, all
fields can have ADDRESSMODIFYCODE (and MAILTOURL) applied except
for a well-defined set (e.g. List-*, Message-Id, etc).

For $SUBJECT$, et. al, ADDRESSMODIFYCODE is applied.  MAILTOURL
is not applied unless the new :M modifier is used for the variable.
This way, the default behavior will not cause conflicts if
rcvar used within hyperlinks.  If MAILTOURL application is
desired, :M must be specifed.

Changes have been committed to CVS and will be part of
the next snapshot build.

Earl Hood <ehood>
Group administrator
Thu 31 Mar 2005 06:36:37 PM UTC, comment #1: 

Mhonarc only does address rewriting on header fields known
to contain addresses.  Rewriting includes mailto linking
along with any spam-related rewriting.

The current list of header fields is
contained in mhutil.pl and it is based upon relevant RFCs and
common mail practices.

The subject field is considered an aribtrary text field, therefore mhonarc does not attempt to apply any rewriting
code.  The reasoning is that such rewriting can have unattended
consequences, not only for how the subject text is used but
for other header fields where such rewriting would not be
desirable (e.g. List-* fields).

One possible solution is to add a new resource that allows
one to specify which header fields may contain addresses vs
using a hard-coded list.  Even with this, special care must
be applied for Subject since a common usage of subject is
in index pages with a hyperlink.  Conflicts, i.e. bad
HTML markup, will occur if mailto linking is done for
Subjects used as hyperlinks on index pages.

Earl Hood <ehood>
Group administrator
Fri 28 Jan 2005 07:29:05 AM UTC, original submission:  

When spammode is on

  * Email addresses in the subject line are not filtered.
    In particular, if one render the subject line using
    $SUBJECTNA$ there can be an unprotected email address.

Jeff Breidenbach <jab>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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 8 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-23 ehood Open/ClosedOpen Closed
2005-07-23 ehood StatusReady For Test Fixed
    Fixed ReleaseCVS 2.6.14
2005-07-08 ehood StatusPostponed Ready For Test
    Perl Version5.8.4 All
    Fixed Release CVS
2005-05-02 ehood StatusNone Postponed
2005-03-31 ehood Operating SystemLinux All

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code