Re: Do we need a new SMTP protocol? (OT)

2010-12-03 Thread João Gouveia


- "Marc Perkel"  wrote:

> I've been thinking about what it would take to actually eliminate spam
> 
> or reduce it to less than 10% of what it is now. One of the problems
> is 
> the SMTP protocol itself. And a big problem with that is that mail 
> servers talk to each other using the same protocol as users use to
> talk 
> to servers.
> 
> Rather than get all users to change maybe it would be easier to get 
> server software to change. This transition can be done by making
> server 
> software that can do both protocols to maintain compatibility but will
> 
> use the new protocol if both sides are capable of talking at that
> level.
> 
> I'm not sure what the specification of the new protocol should be but
> it 
> should at least be different than what email clients use so that
> server 
> to server communication isn't the same as client to server 
> communication. Perhaps server protocols can have more authentication 
> information that would protect them from being spoofed. But having 
> something different - even if it's just a port change - is better than
> 
> what we have now.
> 
> Thoughts?
> 
> (sorry about posting the same message to the dev list. My mistake)

There was a very interesting idea by Bernstein (creator of Qmail).
Time flies. It's now 10 years old... http://cr.yp.to/im2000.html

-- 
João Gouveia
http://mailspike.org/


Re: SUBJECT modified with "****SPAM**** LOW *

2010-12-03 Thread Karsten Bräckelmann
On Fri, 2010-12-03 at 18:40 +0100, Peter Test wrote:
> There is only one thing I can`t manage... I do NOT want to alter the 
> email-subject.
> SA always alters the subject by prefixing a SPAM LOW (or MEDIUM
> or HIGH) * this is also not always the case... only, when the score is
> above 5 or 6... don´t know.

By default, SA does not rewrite any header. The relevant option to do
this is rewrite_header.

However, your rewritten Subject does not appear to be done by SA. It
does not, and in fact can not without custom code, add some distinction
like LOW or HIGH. How exactly do you have SA integrated? I would guess
the glue alters the Subject header, not SA.

Moreover, SA rewrite_header only applies to identified spam. So the
threshold would be 7.5 in your case, not "5 or 6".


> report_safe e.g. works, but adds a report ONLY, if the spam-level is =>
> required value... is this normal?

Yes, by default the X-Spam-Report header is only added for spam.


> # These should be safe assumptions and allow for simple visual sifting
> # without risking lost emails.
> 
> report_safe 0
> required_hits 7.5

required_hits is ancient and deprecated, though still supported as a
synonym for the proper required_score option.


-- 
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}



Re: SUBJECT modified with "****SPAM**** LOW *

2010-12-03 Thread Bowie Bailey
On 12/3/2010 12:40 PM, Peter Test wrote:
> Hi experts,
>
> i just configured spamassassin and it works quite good.
> There is only one thing I can`t manage... I do NOT want to alter the
> email-subject.
> SA always alters the subject by prefixing a SPAM LOW (or
> MEDIUM or HIGH) *
> this is also not always the case... only, when the score is above 5 or
> 6... don´t know.
>
> I can change whatever I want in /etc/mail/spamassassin/local.cf ...
> this behaviour
> does not change... but when I change the required-score value there...
> i see, that
> the value is taken care of... (if i look at the headers of my
> test-mails...)
> So it seems, as if some values are read, others are ignored...
> report_safe e.g.
> works, but adds a report ONLY, if the spam-level is => required
> value... is this normal?
>
> there also is no user_prefs.cf file that could override the
> local.cf... I could nowhere
> find a file, where the "***SPAM***" is added can someone point me
> to solve
> this issue?? I am using SA 3.2.5 in combination with qmail, clamav on
> centos 5.5
>
> local.cf looks like:
>
> # These values can be overridden by editing ~/.spamassassin/user_prefs.cf
> # (see spamassassin(1) for details)
>
> # These should be safe assumptions and allow for simple visual sifting
> # without risking lost emails.
>
> report_safe 0
> required_hits 7.5

By default, SA will not modify the subject.  If SA is doing it, then
there must be a config option either in local.cf, or in one of the
user_prefs files.  (Look for a "rewrite_header" option)

If you are using Amavisd_new or another glue program to interface with
SA rather than calling "spamassassin" or "spamc" directly, then it may
be that the subject tagging is coming from that program rather than
being done by SA.

-- 
Bowie


SUBJECT modified with "****SPAM**** LOW *

2010-12-03 Thread Peter Test

Hi experts,

i just configured spamassassin and it works quite good.
There is only one thing I can`t manage... I do NOT want to alter the 
email-subject.
SA always alters the subject by prefixing a SPAM LOW (or MEDIUM 
or HIGH) *
this is also not always the case... only, when the score is above 5 or 
6... don´t know.


I can change whatever I want in /etc/mail/spamassassin/local.cf ... this 
behaviour
does not change... but when I change the required-score value there... i 
see, that
the value is taken care of... (if i look at the headers of my 
test-mails...)
So it seems, as if some values are read, others are ignored... 
report_safe e.g.
works, but adds a report ONLY, if the spam-level is => required value... 
is this normal?


there also is no user_prefs.cf file that could override the local.cf... 
I could nowhere
find a file, where the "***SPAM***" is added can someone point me to 
solve
this issue?? I am using SA 3.2.5 in combination with qmail, clamav on 
centos 5.5


local.cf looks like:

# These values can be overridden by editing ~/.spamassassin/user_prefs.cf
# (see spamassassin(1) for details)

# These should be safe assumptions and allow for simple visual sifting
# without risking lost emails.

report_safe 0
required_hits 7.5


thank you,
peter t.