[SA-exim] SA-Exim 2.0 released

[Derrick 'dman' Hudson]

---------------------- multipart/signed attachment
On Fri, Jun 14, 2002 at 03:19:09PM -0700, Marc MERLIN wrote:
| On Fri, Jun 14, 2002 at 05:11:04PM -0500, Derrick 'dman' Hudson wrote:
| > On Fri, Jun 14, 2002 at 10:44:04AM -0700, Marc MERLIN wrote:
| > | Finally, it is there.
| > | It compiled cleanly, and my mail server didn't catch fire after runni=
ng it
| > | for 8 hours, so it must be bug free [tm]
| >=20
| > :-).
| =20
| I forgot to mention, you'll also want to upgrade to SA CVS, or the rumour=
ed
| soon to be released 2.30.
| I put a lot of work in SA to make sure it was time bound and fit to run at
| SMTP time.

It was released twice tonight :-).  I expect to see the .deb soon.

| > |     * Support X-Spam-Status from SA pre 2.30
| >=20
| > I don't understand this one.  I'm using SA 2.20 and have been using
| > sa-exim 2.0b1 for the past 2 days.  I don't see anything wrong in
| > mainlog.
| =20
| If you upgrade to SA pre 2.30, sa-exim 2.0b1 and older will fail to parse
| the X-Spam-Status that SA now generates.

Do you mean SA newer than 2.20 but older than 2.30?
 =20
| > | Note that you will need this version to run the more recent
| > | SpamAssassin code, they changed the format of X-Spam-Status.
| >=20
| > That's going to break my mutt hooks :-(.  I've got a pair of
| > message-hooks to only display that header (in my pager) if some test
| > triggered.
|  =20
| It's a multiline header now.
| Probably just as well, because the line was getting quite long.

That's all?  It's already multiline (sometimes) and the mutt hooks are
handling it just fine.  I thought maybe they rearranged the order or
name of the arguments.
  =20
| > Another possibility is to annoy the other admin even more.  RFC 1047
| > recommends a 5-10 minute timeout for receiving the response.  You
|=20
| That's why the time to sleep is an option.

I see that now.  (I hadn't grabbed the new config file before)

| > | Note too  that SA  2.30 pre  currently outputs *very  long*
| > | headers  in some cases, and it goes beyond SA's 8KB limit for
| > | string_sprintf.  So you'll want to change
| > | STRING_SPRINTF_BUFFER_SIZE in exim/src/config.h.defaults
| >=20
| > Hmm, I don't see any size limits in RFC 2822 (line limits don't count
| > if the header is properly wrapped).  You mentioned this was in
| > relation to the spam phrases test. =20
|=20
| Yep. See:
| http://bugzilla.spamassassin.org/show_bug.cgi?id=3D444

| I just read they're apparently not going to fix that for SA 2.30

Duncan has a patch already.  Cool.  I'll have to patch my local copy
to not spew that list at all (when the package is uploaded).

It certainly is easier to not generate the text than it is to parse it
and reliably throw away what you don't want.

Of course, in some circumstances you have no control over the spewing
of worthless bytes, and I've been working on a set of filters to take
care of that.  For much of my incoming mail, I strip off MLM tag
lines, virus scanner notices, legal notices, and other worthless stuff
like hotmail and yahoo ads.  I should make it distributable and post
it some time.  If you want to play with it sooner, let me know.

| > I know that postfix truncates data when it logs to prevent any
| > potential exploit or DoS as a result of excessive data.  (for example,
| > read Wietse's paper on the origin of tcp-wrappers and the use of
| > finger)=20
|=20
| Exim has a safeguard, but it will just die if it detects that you are try=
ing
| to write too much data.

Nice.  Does it die an quick and honorable death or does it writh in
slow agonizing pain?  ;-)  I certainly hope it is an honorable death
that includes cleaning up after itself, rather than just vanishing.

-D

--=20

In the way of righteousness there is life;
along that path is immortality.
        Proverbs 12:28
=20
http://dman.ddts.net/~dman/


---------------------- multipart/signed attachment
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.merlins.org/archives/sa-exim/attachments/de7ef02c/attachment.bin

---------------------- multipart/signed attachment--