Created attachment 344 [details]
Sample message from Network Solutions

Created attachment 345 [details]
Sample message from Register.com

Followup: Justin asked me to forward some samples of the "transfer 
approval" messages from Network Solutions and register.com, in the 
hope that some better method of whitelisting than the From address 
could be used.

Unfortunately, I do not have the full headers of any samples, as I haven't 
directly received these messages myself. However, I do have copies of 
the message bodies that my customers have forwarded to me, and these 
may be useful for finding whitelist approaches.

I have added them as attachments to the bug (ID numbers and domain 
names are replaced with "XXXXXX").

For what it's worth, a unique string suitable for whitelisting in the Network 
Solutions messages is probably "http://www.stayoffer.com/".

In this case of the register.com message, a unique string would probably 
be "http://register.com/t/". (The other one -- "https://secure.register.com/
renewals/" -- seems like something that might potentially appear in spam 
from register.com affiliates.)

Hope this helps.

Subject: Re: [SAdev]  60_whitelist.cf should contain outbound-response@networksolutions.com and customersupport@register.com

bugzilla-daemon@hughes-family.org writes:

> Unfortunately, I do not have the full headers of any samples, as I haven't 
> directly received these messages myself. However, I do have copies of 
> the message bodies that my customers have forwarded to me, and these 
> may be useful for finding whitelist approaches.

Messages without the full original text (SA-added headers are okay) are
basically unusable for SpamAssassin development.  That means, both full
headers and full body with the original spacing (don't cut-and-paste).

Why?  We can't make tests that are appropriately specific or generalized
without them.  We are missing important data.

>Messages without the full original text (SA-added headers are okay) are
>basically unusable for SpamAssassin development.  That means, both 
full
>headers and full body with the original spacing (don't cut-and-paste).

Well, as I said, the original messages weren't sent directly to me, so I 
don't have them in original format, unfortunately.

I realize that if a rule is going to be subjected to the GA, it should have 
samples of the full messages; my original suggestion was that the From 
addresses be added to 60_whitelist.cf -- but Justin said that From 
addresses alone will no longer be used for whitelisting, so I sent along 
what I had instead.

The next time someone forwards one of these to me, I will ask them to 
send full headers (but some parts will still need to be munged before I 
submit it, because the actual transfer codes are confidential). I'll also ask 
a few of the more recent recipients if they still have copies they could dig 
up.


>Why?  We can't make tests that are appropriately specific or generalized
>without them.  We are missing important data.

Yes, I agree more data is always better, but I don't have it, unfortunately.

I think it would be possible to make appropriately specific tests based on 
what's there; for example, the following rule would appear appropriate:

body DOMAIN_TRANSFER        /http:\/\/www\.stayoffer\.com|http:\/\/register\
.com\/t\//
describe DOMAIN_TRANSFER    Domain name transfer message

But I realize that without full samples of such messages in a corpus, 
there's no way to make sure the rule correctly inhibits false positives. As I 
said, when/if I can get more info in the future, I'll provide it.

I appreciate the effort, but please don't bother attaching examples unless
each is a full message.  We have a system for whitelisting and we need to
use more headers than the ones you have provided.  And it would be sloppy
to write a rule based on partial information, so I'm not going to do that
either.

I would normally close this bug as INVALID at this point, but I don't want to
allow Network Solutions transfer confirmations to be marked as spam (as they
seem to desire).

(assigning bug to myself)

>I appreciate the effort, but please don't bother attaching examples unless
>each is a full message.  We have a system for whitelisting and we need 
to
>use more headers than the ones you have provided.  And it would be 
sloppy
>to write a rule based on partial information, so I'm not going to do that
>either.

Well, I apologize, but I wasn't withholding information out of malice or 
stupidity; you're chastisting me for something I can't control. I simply don't 
have complete copies of the messages in question.

Justin asked for samples, and I provided what partial information I had -- 
with a disclaimer that I knew it wasn't ideal -- on the theory that as a 
starting point, a partial clue about the problem was better than nothing.

As I said, if I can get better information, I will provide it.


>I would normally close this bug as INVALID at this point, but I don't
>want to allow Network Solutions transfer confirmations to be marked as
>spam (as they seem to desire).
>
>(assigning bug to myself)

Thanks.

Created attachment 346 [details]
NSI sample with headers

Well, I found *something* that mnight help; it's a password-change msg
from register.com in 2000. attached.  here's the lines as a result.

whitelist_from_rcvd  outbound-response@networksolutions.com networksolutions.com
whitelist_from_rcvd  customersupport@register.com           outgoing


the last one is tricky; the line is 
Received: from wwwn.register.com (outgoing2.jrcy.register.com [209.67.50.16])

Created attachment 369 [details]
register.com customersupport mail sample w headers

I added outbound-response@networksolutions.com, but since I lack a recent
register.com example with full headers, I don't think I should add that.

(marking as fixed, although it's perhaps 50% fixed and 50% invalid)