On Sat, Mar 08, 2003 at 08:27:19PM +0000, Jason Chambers wrote: > On Mar 8 13:44, ScruLoose wrote: > > poked at the man page some, commented out no_bouncemail, so fechmail_daemon > > is no longer spamming me (local postmaster) with the error, *but* I don't > > know what syntax it wants for values of 'antispam'. > > The smtp command timeout *is* still quietly showing up in exim's log. > > > > I know that 'antispam' is referring to the smtp return-values, and I figure > > I want it set to 5## This will make fetchmail hard-refuse (ie "return to > > sender, quit trying to deliver this here") any message that causes a 5xx > > SMTP error... yes? > > > > And I suspect that a value of -1 means "never match anything"... yes? > > So am I right in thinking that 'set antispam 5##' is what I want? > > And if so, what's the right syntax for matching any 5## response? > > > > If you don't specify the antispam option it is set to a list > of sensible defaults - which includes 501 for Exim (as it doesn't give > a specific spam rejection code yet). Hum. Okay, that's done, and it seems to have solved it. Gotta love those sensible defaults! > Fetchmail refuses anything other than a comma separated list > of numbers for the antispam option, so if you want to set it to 500-599 > then your only option is to specify every code manually or leave it out > all together (the later solving you problem anyway). I see, okay. As things stand, I don't feel the need to argue with fetchmail's defaults on this. > If you've also got the spambounce option set it will cause messages > rejected due to the antispam option to be bounced to the sender. I haven't set this so far... Can't imagine it would really do any good, would it? I mean, even assuming it manages to actually get back to the sender, the spammer is munging things on purpose and doesn't care about a few bounces, right? > You will still see the timeout error in Exim's log but it should only > happen once for each message. If you're logging fetchmail anywhere > you should see that it has discarded the message. Okay, that's perfectly okay by me. As long as it now knows when to *give up* on a message, instead of trying and failing... choking on the *same* message with every fetch... > Jason Chambers (chambersj@chambersj.dyndns.org) > Leicester, England Thank you *very* much. That straightened it out nicely. Now, I'm curious as to what's really going on in there... let me see if I've got it right: 1. Fetchmail makes a POP3 connection to my ISP, starts suckin' down messages. 2. Fetchmail grabs a connection to exim on localhost (exim as a 'listener') 3. Exim either delivers the mail successfully and returns 0, or chokes on it and returns one of a variety of error codes (depending on why and how it choked). 4. Fetchmail deletes the mail from the POP-server *only* after Exim returns "okay, I got it" More or less? So... what is it about a mail that causes exim to say "ick! this is spam" and thus return 501... I don't have spamassassin or anything... this is exim itself having this response, right? Obviously, this is not an urgent point, as my particular situation is solved... but I'm curious, so any info or links to good reading on this would be welcome. Thanks again, -Chris
Attachment:
pgpSZlrybQbfF.pgp
Description: PGP signature