Think of this anology:
If somebody calls me on my home phone, I immediately see his nr. (If I don't
see a nr. I don't pick up my phone at all). Now, the first thing I'd expect
someone to say when I pick up is his name. If people start talking to me
without stating who they are, it is commercial sh*** 95% of the time and I just
hang up.
It's a matter of being polite. Very regularly e-mail addresses are unindicating of the person's name, for example only containing initials.
It basically comes down to this, if a real name is not specified the chance
that it is spam is considerable and it should be scored a couple of points.
-Sietse
From: Chris Lear
Sent: Thu 07-Dec-06 15:06
To: users@spamassassin.apache.org
Subject: Re: SV: Help with understanding a rule
* [EMAIL PROTECTED] wrote (07/12/06 12:03):
The list managers are the first ones who have to change.
Yes, you are probably right. But: there must be a reason why the
rule no_real_name exists? And if there is a rule (written or not)
that From: headers should contain a real name, I want to follow it.
And to follow it I need to convince my IT staff somehow...
So, what is the reason behind no_real_name?
Most MUAs, most of the time, put a real name into mail they send. It's
standard setup. So not having a real name is, perhaps, a spam sign This
isn't the same as contravening RFCs. Remember that there's a rule called
HTML_MESSAGE as well, which might be a spam sign. Both of these are
bound to hit ham a lot of the time, so scoring them high would be, at
best, an unusual decision. Scoring them high enough to reject would be
very unusual.
As it happens, on a server I manage NO_REAL_NAME hits 5% of spam, and
25% of ham (much of which is not MUA-originated). So it's not a rule I'd
like to reject on.
But if a mailing list or a user has a "you must provide a real name"
policy, spamassassin's flexible enough to be able to enforce it.
Chris
