Subject: Re: [SAdev]  New: <headername>_MALFORMED rules do not conform to RFC(2)822 specifications

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 17 Apr 2002 2:52 pm, bugzilla-daemon@hughes-family.org wrote:
> http://www.hughes-family.org/bugzilla/show_bug.cgi?id=219
>
> I don't personally use spamassassin, however, I discovered it had warned
> about a malformed to line. I'm fairly careful to make sure that such
> headers are not malformed, and so I did a bit of investigation. The failing
> header looked like:
>
> To: Colon MOTD Announce :;
>
> This is a valid To: line (conforming to RFC2822 S3.4 or RFC822 S6.1 (cf
> specification for "group", as a possibility for "address"). I wondered how
> close to the RFC its parsing was, so I sent a mail with an RFC(2)822
> addr-spec valid from line of:
>
> From: Matthew Byng-Maddick <#!|`' . mbm . 007.&?*%$@colondot . net>
>
> which has folding whitespace in allowed places, and correct atom
> characters. This is deliverable to me on the receiving system, as verified
> afterwards, and was also flagged up as having a malformed From: line.
>
> Despite the obvious contrivedness of this latter, the former came up as
> part of an automated system to send out important messages to my users on
> my box, so I was a little worried that it was even slightly flagged as spam
> for an apparently "malformed" address.
>
> I feel it would be correct to say "Spam-like <headername> header" or
> whatever, but not "Malformed" because they are both very definitely
> correctly formed.
>
> Can this be changed to conform to the relevant RFCs, please?

Hi Matthew (our paths cross once again ;-)

No, it can't be changed to conform to the relevant RFCs. The point of the rule 
is not to be 100% compliant, but to catch unusual addresses. Perhaps the 
description of the rule could be changed to reflect that more carefully. The 
point being that we want to catch out mail that is not coming from the 
majority of email clients out there. As a general rule, these email clients 
generate email addresses in a very simple set of formats, and so we are 
really looking for deviations from that.

I assume your email wasn't actually flagged as spam (judging from what you 
wrote), so I take that as proof that SpamAssassin is actually working 
perfectly well in this situation - one false positive rule won't make the 
whole email get caught as spam.

- -- 
Matt.
<:->get a SMart net</:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vYXw5tFry5Ir+lARAnC6AJ9sBBUyHm9HSEksg/T0Qh1dPsabVQCfahY6
aySalqz8Td2ch0loCvTJ0Gg=
=eN/b
-----END PGP SIGNATURE-----

Subject: Re: [SAdev]  New: <headername>_MALFORMED rules do not conform to RFC(2)822 specifications

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 17 Apr 2002 2:52 pm, bugzilla-daemon@hughes-family.org wrote:
> http://www.hughes-family.org/bugzilla/show_bug.cgi?id=219
>
> I don't personally use spamassassin, however, I discovered it had warned
> about a malformed to line. I'm fairly careful to make sure that such
> headers are not malformed, and so I did a bit of investigation. The failing
> header looked like:
>
> To: Colon MOTD Announce :;
>
> This is a valid To: line (conforming to RFC2822 S3.4 or RFC822 S6.1 (cf
> specification for "group", as a possibility for "address"). I wondered how
> close to the RFC its parsing was, so I sent a mail with an RFC(2)822
> addr-spec valid from line of:
>
> From: Matthew Byng-Maddick <#!|`' . mbm . 007.&?*%$@colondot . net>
>
> which has folding whitespace in allowed places, and correct atom
> characters. This is deliverable to me on the receiving system, as verified
> afterwards, and was also flagged up as having a malformed From: line.
>
> Despite the obvious contrivedness of this latter, the former came up as
> part of an automated system to send out important messages to my users on
> my box, so I was a little worried that it was even slightly flagged as spam
> for an apparently "malformed" address.
>
> I feel it would be correct to say "Spam-like <headername> header" or
> whatever, but not "Malformed" because they are both very definitely
> correctly formed.
>
> Can this be changed to conform to the relevant RFCs, please?

Hi Matthew (our paths cross once again ;-)

No, it can't be changed to conform to the relevant RFCs. The point of the rule 
is not to be 100% compliant, but to catch unusual addresses. Perhaps the 
description of the rule could be changed to reflect that more carefully. The 
point being that we want to catch out mail that is not coming from the 
majority of email clients out there. As a general rule, these email clients 
generate email addresses in a very simple set of formats, and so we are 
really looking for deviations from that.

I assume your email wasn't actually flagged as spam (judging from what you 
wrote), so I take that as proof that SpamAssassin is actually working 
perfectly well in this situation - one false positive rule won't make the 
whole email get caught as spam.

- -- 
Matt.
<:->get a SMart net</:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vYXw5tFry5Ir+lARAnC6AJ9sBBUyHm9HSEksg/T0Qh1dPsabVQCfahY6
aySalqz8Td2ch0loCvTJ0Gg=
=eN/b
-----END PGP SIGNATURE-----


_______________________________________________
Spamassassin-devel mailing list
Spamassassin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spamassassin-devel

Re: paths crossing, absolutely :-)

It did actually flag one as spam, but this is partly my fault, because I'd cut
and paste the message from my editor, and so headers that normally get stripped
by the  MUA were not stripped in this case.

I feel it would be sensible to have a ruleset that is "Malformed" and one that
is say, "Unusual formation" which perhaps doesn't score so highly. Certainly
calling it "malformed" seems like a bug to me, where it is an unusual formation
but not an incorrect one. Certainly I see the value of scoring down unusual
formations of header lines.

It's particularly that after many discussions (some rather too heated) about the
interpretation of Mail RFCs in various places, I feel that making something that
doesn't imply a non-standards-compliant system is very important. I think that
the current rules would go well as TO_UNUSUAL and FROM_UNUSUAL, I just don't
think that they're sensibly called TO_MALFORMED and FROM_MALFORMED.

Subject: Re: [SAdev]  <headername>_MALFORMED rules do not conform
 to RFC(2)822 specifications

...and if you're french, both MALFORMED and UNUSUAL are wrong.  I'm not even
going to get into the complication of 8-bit rulenames for our friends who don't
use the roman alphabet.

Subject: Re: [SAdev]  <headername>_MALFORMED rules do not conform
 to RFC(2)822 specifications

...and if you're french, both MALFORMED and UNUSUAL are wrong.  I'm not even
going to get into the complication of 8-bit rulenames for our friends who don't
use the roman alphabet.


_______________________________________________
Spamassassin-devel mailing list
Spamassassin-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spamassassin-devel

I'm going to close this, I think the issue is settled.