You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/04/22 21:12:17 UTC
[Bug 6097] New: spamc/spamd
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6097
Summary: spamc/spamd
Product: Spamassassin
Version: 3.2.5
Platform: Other
OS/Version: Linux
Status: NEW
Severity: major
Priority: P3
Component: spamc/spamd
AssignedTo: dev@spamassassin.apache.org
ReportedBy: neilperrins@favio.co.uk
Since you have closed my "bug" and your email does not accept replies, the only
way I can reply is to open another Bug.
I've tried to be more responsible with my "Priorities", but what is a higher
priority than not being able to use the software? And this is true for many
non-SA geeks.
Anyway, here is my reply to your response:
Karsten,
First of all, I should say that I do appreciate all your efforts. And, I do
appreciate Spamassassin when it works. But I have to take exception to a few of
your comments.
Your web-pages and web-site set up is deliberately restricting feedback.
Average users are not going to subscribe or sign-up. They just want a solution
to their problem. Your site doesn't have a way in to tell you of the problems
most non-specialists are experiencing. So how do you (not them) know what their
FAQs are? You never get them.
Now in response to your comments:
> You neglected to mention how you actually try to integrate SA. But
> reading this, an obvious comment is, that SA does not alter mailboxes...
My Spamassassin is installed as part of Fedora Core 10. I just altered the
configs as shown by Spamassassin site and elsewhere (and I find a lot of
elsewhere sites more useful....not a dig, just the truth of it. They are easier
to understand.)
"Spamassassin does not alter mailboxes?" Mine doesn't alter the email. Inbound
email, mailbox email or outbound email - Spamassassin doesn't touch any of it.
Spamassassin does not put any headers on the mail and therefore blocks nothing.
In the old days, every email was given a set of spam headers with a score.
That's the way I understood it to work.
If I pipe my mailbox through spamc and back to my mailbox file....bingo, all
the emails have spam scores and things get blcoked. Trouble is, I have to run
this script every two minutes to beat the 5 minute downloads from users. And
doing this means that it tests the same emails over and over again.
I have tried setting up procmail and .forward, but nothing wants to work. I am
SO desperate to get rid of hundreds of spam emails that the script method seems
the only option at the moment. Believe me, I want Spamassassin to be
" ...integrated in (my) mail processing chain. Not as an after-delivery
mailbox-munging service."
but since this cannot be made to work on my system and there are no
instructions, no diagnostics, no testing, anywhere on the web, I am reduced to
Heath-Robinson lash-ups.
The answer is totally in the method of transport of the emails and how they
route through spamc, but each step has to be tested. You guys may well now how
it works and how to test it, but us mere mortals have no idea. A step by step
diagnostics process please.
Seriously, if you want real user feedback, don't rely on the "Spamassassin
officianados" who have user accounts. They may be highly intelligent
individuals, but they aren't "real" everyday people.
All I know is that, in the past, my email turned up on the client with a score.
It doesn't now. I don't know whether the headers were put on before during or
after the mailbox, so I have no way of diagnosing the problem (even if I knew
how sendmail/procmail worked). And it is for that reason that I am intrigued
when you say " SA does not alter mailboxes...". This could only be true if
Spamassassin runs AFTER the email is called for. Or is that statement really
true? Are you telling me that, on a server that has Spamassassin running, that
the email that resides in people's mailboxes does not have Spamassassin
headers? Or are you being manipulative with the English language? i.e. "It
doesn't change the mailboxes, it only changes the email inside them."
Neil
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6097] spamc/spamd
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6097
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #1 from Kevin A. McGrail <km...@pccc.com> 2009-04-22 12:25:27 PST ---
Neil,
SpamAssassin can be used to modify emails but it doesn't modify mailboxes.
So in the configuration you are working with, you have something accepting
emails (qmail, Sendmail or Postfix) and something delivering those emails to
the mailbox. In sendmail, this is typically procmail.
Hence, you can tie-in SpamAssassin in a sendmail environment by editing the
procmailrc file to call SA on a sitewide basis.
You can further extend this call to use spamc/spamd to increase the efficiency
of the tie-in.
Postfix, from memory, also uses procmail to deliver the mail to your mailbox.
So in short, *YOU* have to figure out the site-wide configuration technique
that will call Spamassassin via the mailbox delivery vehicle that is in use in
your configuration.
This is not a bug and you should join the users list for more assistance.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6097] spamc/spamd
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6097
Karsten Bräckelmann <gu...@rudersport.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|major |normal
Priority|P3 |P5
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6097] spamc/spamd
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6097
Karsten Bräckelmann <gu...@rudersport.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Karsten Bräckelmann <gu...@rudersport.de> 2009-04-22 13:02:23 PST ---
(In reply to comment #0)
> Since you have closed my "bug" and your email does not accept replies, the only
> way I can reply is to open another Bug.
Closing properly as duplicate of bug 6096.
Neil, there is no need to open a new bug, if you want to leave a comment. You
can do that to already resolved bugs, too. However, the email you got is merely
an automated notification of bugzilla. It's not meant to receive email,
including replies and follow ups.
> I've tried to be more responsible with my "Priorities", but what is a higher
> priority than not being able to use the software? And this is true for many
> non-SA geeks.
The usual bugzilla problem -- "It doesn't work for me" doesn't make it a
blocker, if it works for anyone else. ;) Even more so, since this really only
is an issue with integrating SA into whatever environment you have.
> but since this cannot be made to work on my system and there are no
> instructions, no diagnostics, no testing, anywhere on the web, I am reduced to
> Heath-Robinson lash-ups.
You already confirmed SA is working. The missing bit is the *integration*,
that's configuring your MTA or MDA to use SA.
This is not a SA problem. Seriously, it's out of scope for this bugzilla. The
web-site however of course still holds examples, showing exactly this. Also,
the list will be willing to lend you a hand to set up your services to properly
use SA for filtering.
> The answer is totally in the method of transport of the emails and how they
> route through spamc, but each step has to be tested. You guys may well now how
> it works and how to test it, but us mere mortals have no idea. A step by step
> diagnostics process please.
And again, you failed to mentioned your mail processing chain. No one can help
you, if *you* don't know what *you* are running that should use SA. (Hint: The
mailing list will need to know that, too.)
> Seriously, if you want real user feedback, don't rely on the "Spamassassin
> officianados" who have user accounts. They may be highly intelligent
> individuals, but they aren't "real" everyday people.
SA is not a software typically run by or intended for the average user. SA is a
server-type tool for administrators.
*** This bug has been marked as a duplicate of bug 6096 ***
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.