Justin,
I've been trying to get some help setting up SA on a windows server. I was
finally able to get it integrated and working. But it messed up our incoming
mail. Some how an extra linefeed was feed into the email begining with the
first line. The result was that all mail readers interpret the message as a body
only. The messages did get delivered but you had no date or sender or subject
lines to read before opening the message. Yet all of my manual testing produced
perfectly normal output.
If you have any ideas I'd really appreaciate hearing them.
My setup:
Using the latest perl for windows.
Using SA 2.31
Configured for site wide as individual is not workable with my MTA at this
moment.
Command line to activate sa:
spamassassin -P -F0 < infile > outfile
Notes:
SA is runing from a batch file that was auto-generated.
I've tried both the .pl and the .bat with the same results in testing and
implementation.
The -P must be used or SA hangs as the $MAIL is undefined on the system (I'd
have to write a program to parse the email, get the recipient, make a path to
the correct mbox, set the $MAIL variable to that path and then launch SA (if I
wanted to define it!)).
I'm using VBScript to launch SA, pass it the temp file name to use for input and
output. It then copies the output file overwriting the original input and
signals my MTA to carry on by returning an exit code of 0.
The -F0 seemed to be needed for my MTA, I also tried -F 0, I'm not sure which is
correct but both seem to cause the reordering of FROM: to the first line.
I can't think of anything else that could be helpful. I'm confident that the
problem lies with SA because it uses my MTA's temp file as the input and creates
a new output file, I then copy that file over the original without doing
anything to it. So the extra line feeds are generated by SA. I just can't figure
out how to get rid of them or configure SA to not add them.
Justin Mason wrote:
>
> Hi all --
>
> If anyone's been checking taint.org, they might have noticed that I'm back
> in contact -- although I'm taking my sweet time to get my mail setup
> working decently again ;)
>
> Anyway, some quick notes on SpamAssassin dev based on a skim of recent
> traffic:
>
> - regarding lists and 'my address' stuff. One thing I should note is that
> the *previous* spam filter I used supported both recognising "legit"
> list mails, and recognising your own address in order to penalise mails
> which aren't explicitly addressed to you. Here's why they were bad IMO:
>
> - spammers are already using "legit" list manager software, possibly to
> get past some filters - I've seen Lyris ListManager used (iirc).
> Probably helps in bulk-mailing large lists of recipients, too, so it
> makes sense.
>
> - Dunno about you guys, but I get a whole load of spam via mailing
> lists whose addresses are on CDs. I want SpamAssassin to catch spam sent
> to a list, as well as it catches spam sent to me directly.
>
> - Using knowledge of "the user's address" to figure out if a mail was
> sent to you, or to a list, means additional customisation is *required*
> for anyone setting up SpamAssassin, unless we figure it out
> automatically.
>
> Also means that any forwarding set up from [EMAIL PROTECTED] to
> [EMAIL PROTECTED], will require modification of the "my address" setting.
> Ditto for any new mailing lists you may subscribe to. Lots of
> customisation required, continually, which is a pain.
>
> Bcc'd mails are already penalised. This will penalise them more.
>
> Now, I can see the top reason it'd be useful, however. Spammers are
> using the dest. address as the forged From address, since that is almost
> always in the AWL as a non-spamming addr. If we can come up with some
> way to work around this *without* requiring a "my address" or "my
> domain(s)" setting or regexp -- ie. using some stats analysis on the AWL
> data instead -- it would be infinitely preferable...
>
> - I'm going through the CVS version, fixing some over-aggressive or borken
> rules. hope no-one minds ;)
>
> - Quick query on a comment in PerMsgStatus: it claims that the body-text
> rules are faster if called procedurally. How is this? And how come
> passing $_ as an arg instead of \$_ is faster?
>
> I'm sure there'll be more questions, and I'll probably accidentally undo
> someone else's rule changes from the past few months, through ignorance of
> what's been going on, so I'll apologise in advance ;)
>
> cheers,
>
> --j.
>
> --
> 'Justin Mason' => { url => 'http://jmason.org/', blog => 'http://taint.org/' }
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Spamassassin-talk mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
--
========================
Kevin W. Gagel
Network Administrator
College of New Caledonia
[EMAIL PROTECTED]
[EMAIL PROTECTED]
(250)562-2131 loc. 448
========================
--------------------------------
The College of New Caledonia
Visit us at http://www.cnc.bc.ca
--------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
