Skip Menu |
 

This queue is for tickets about the Mail-SPF CPAN distribution.

Report information
The Basics
Id: 70469
Status: stalled
Priority: 0/
Queue: Mail-SPF

People
Owner: Nobody in particular
Requestors: d.stussy [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Issue - Mail::SPF - Parentheses in comments/text et. al.
Date: Wed, 24 Aug 2011 15:33:01 -0700 (PDT)
To: bug-Mail-SPF [...] rt.cpan.org
From: d.stussy [...] yahoo.com
Download (untitled) / with headers
text/plain 1.7k
Typical usage (example - Sendmail virtual hosting and MimeDefang): my $spfserver = Mail::SPF::Server->new(max_void_dns_lookups => undef, hostname => $SendmailMacros{'if_name'} ); my $spfrequest = Mail::SPF::Request->new(versions=>[1], scope=>'mfrom', identity => $id, ip_address => $ip, helo_identity => $helo); my $r = $spfserver->process($spfrequest); my $result = $r->code; my $local = $r->local_explanation; my $label = ($sender eq "<>") ? 'helo' : 'mailfrom'; ... action_insert_header('Authentication-Results',$SendmailMacros{'if_name'}. "; SPF=$result smtp.$label=$1 ($local)", 1) if ...; Result inserted into message (RFC 5451 format): Authentication-Results: example.com; SPF=pass smtp.mailfrom=example.net (example.net: 2001:db8::dead:beef:cafe is authorized to use 'sysop@example.net' in 'mfrom' identity (mechanism 'mx' matched)) $r->local_explanation returns a text string that is meant to be used as a comment for the result. However, SMTP messages (STD 10: RFC 5321 and 5322) do not allow nested comments. Parentheses may not appear in comments. The problem is that "local_explanation" returns parentheses in its string, so when the string is turned into a comment, it causes nested comments in violation of Internet mail standards. Please, would "local_explanation" be rewritten so that no result returned contains parentheses? It would also be cleaner not to have the domain queried about repeated in the explanation at the beginning of the string, as it is redundant when quoting the mailbox tested. Since I'm using the RFC 5451 format for reporting the results, not RFC 4408's original format of "Received-SPF:" headers, the returned variable received_spf_header has not been checked for similar problems. I leave that to the author/maintainer to determine.
On 2011-08-24 18:33:12, d.stussy@yahoo.com wrote: Show quoted text
> [...] > Result inserted into message (RFC 5451 format): > > Authentication-Results: example.com; SPF=pass > smtp.mailfrom=example.net (example.net: 2001:db8::dead:beef:cafe is > authorized to use 'sysop@example.net' in 'mfrom' identity > (mechanism 'mx' matched)) > > > $r->local_explanation returns a text string that is meant to be used > as a comment for the result. > > However, SMTP messages (STD 10: RFC 5321 and 5322) do not allow nested > comments. Parentheses may not appear in comments.
Not true. http://tools.ietf.org/html/rfc5322#section-3.2.2 : ctext = %d33-39 / ; Printable US-ASCII %d42-91 / ; characters not including %d93-126 / ; "(", ")", or "\" obs-ctext ccontent = ctext / quoted-pair / comment comment = "(" *([FWS] ccontent) [FWS] ")" <comment> may contain <ccontent>, which in turn may be a <comment>. Agreed?
Subject: Re: [rt.cpan.org #70469] Issue - Mail::SPF - Parentheses in comments/text et. al.
Date: Wed, 24 Aug 2011 17:13:14 -0700 (PDT)
To: bug-Mail-SPF [...] rt.cpan.org
From: d.stussy [...] yahoo.com
Download (untitled) / with headers
text/plain 1.7k
--- On Wed, 8/24/11, Julian Mehnle via RT <bug-Mail-SPF@rt.cpan.org> wrote: Show quoted text
> On 2011-08-24 18:33:12, d.stussy@yahoo.com wrote:
> > [...] > > Result inserted into message (RFC 5451 format): > > > > Authentication-Results:   example.com; SPF=pass > >    smtp.mailfrom=example.net (example.net: 2001:db8::dead:beef:cafe is > >    authorized to use 'sysop@example.net' in 'mfrom' identity > >    (mechanism 'mx' matched)) > > > > > > $r->local_explanation returns a text string that is meant to be used > >    as a comment for the result. > > > > However, SMTP messages (STD 10: RFC 5321 and 5322) do not allow nested > >    comments.  Parentheses may not appear in comments.
> > Not true. > > http://tools.ietf.org/html/rfc5322#section-3.2.2 : > >    ctext           =   %d33-39 /          ; Printable US-ASCII >                        %d42-91 /          ;  characters not including >                        %d93-126 /         ;  "(", ")", or "\" >                        obs-ctext > >    ccontent        =   ctext / quoted-pair / comment > >    comment         =   "(" *([FWS] ccontent) [FWS] ")" > > <comment> may contain <ccontent>, which in turn may be a <comment>. > Agreed?
I missed that. I was thinking of another situation when I wrote that. However, [some] nested comments are still confusing when read by humans. Instead of using parentheses, maybe a dash would be clearer? In plain language, people generally do not nest parentheses. Sample: (2001:db8::dead:beef:cafe is authorized to use 'sysop@example.net' in 'mfrom' identity - mechanism 'mx' matched) I still think that the domain name prefix of the string should be dropped.
Download (untitled) / with headers
text/plain 1.1k
On 2011-08-24 20:13:30, d.stussy@yahoo.com wrote: Show quoted text
> I missed that. I was thinking of another situation when I wrote that. > However, [some] nested comments are still confusing when read by > humans. Instead of using parentheses, maybe a dash would be > clearer? In plain language, people generally do not nest > parentheses. > > Sample: > (2001:db8::dead:beef:cafe is authorized to use 'sysop@example.net' in > 'mfrom' identity - mechanism 'mx' matched) > > I still think that the domain name prefix of the string should be > dropped.
I don't think changing the format of the local_explanation string is a good solution because, whereas your points may have merit, they are somewhat arbitrary and a matter of taste. There would soon be someone else who would rather have double quotes instead of single quotes, etc. The proper solution is to build an explanation string of your own. If you can't get all the necessary details from the result object (other than by parsing/dissecting the explanation string, which would be a very bad idea), then I'd be happy to add methods to expose them. Please let me know what details you need to build your own explanation string.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.