Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
snowcrash+openbsd writes: > > You've got the source. Why not read it and figure out the answer for > yourself? > > Source being available is true for just about everything, now, isnt't it? Well, I see you quoted from a private message I sent, and a selected quote at that. While noting that I said you could read the source to get your answers you neglected to mention that I read it for you and explained *exactly* what setting the delay to zero would do. > Signing off now -- just not worth the effort in here. Bye. // marc
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
> You've got the source. Why not read it and figure out the answer for yourself? Source being available is true for just about everything, now, isnt't it? Surprising, then, that people ask questions ... Thanks for all the advice to use my MTA, everyone! The pissy off-list insults are a nice touch, too! Signing off now -- just not worth the effort in here.
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
* snowcrash+openbsd <[EMAIL PROTECTED]> [2007-09-11 11:41]: > hi, > > > it does this offline after one delay > > well, fair enough, then. > > what, then, is the MINIMUM value of that delay? > > "1 minute" is obviouly OK. Nope, because it's up to the client (the other end) how fast he retries. > > *is* zero delay "code functional" (does it *break* anything)? i.e., > the second attempt (after one "zero" delay ...) is passed? yes, it would be functional from smtpd's perspective, but totally stupid because mailers out there talking to it don't work that way. > > afaict, delays in seconds are NOT allowed, are they? just integer-minutes? > It doesn't matter. For what you want to do - use your MTA -Bob
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
> You *do* understand that the second attempt can occur at any random time > of the sending MTA's choice, or even never? Yes. Irrelevant. I'm asking about spamd's behavior. Not the sender's. > Just use your MTA's built-in features. One can do EVERYTHING spamd does with the MTA ... It seems that that's what *you* would like to do. Great. That's neither (a) what i'm interested in, nor (b) what I'm asking about. So, *do* you know what, if any, values 0 <= x < 1 are allowed by spamd code? If not, thanks for your input :-)
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
On Tue, Sep 11, 2007 at 10:31:31AM -0700, snowcrash+openbsd wrote: > > it does this offline after one delay > > well, fair enough, then. > > what, then, is the MINIMUM value of that delay? > > "1 minute" is obviouly OK. > > *is* zero delay "code functional" (does it *break* anything)? i.e., > the second attempt (after one "zero" delay ...) is passed? > > afaict, delays in seconds are NOT allowed, are they? just integer-minutes? You *do* understand that the second attempt can occur at any random time of the sending MTA's choice, or even never? Just use your MTA's built-in features. Joachim -- TFMotD: trpt (8) - transliterate protocol trace
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
hi, > it does this offline after one delay well, fair enough, then. what, then, is the MINIMUM value of that delay? "1 minute" is obviouly OK. *is* zero delay "code functional" (does it *break* anything)? i.e., the second attempt (after one "zero" delay ...) is passed? afaict, delays in seconds are NOT allowed, are they? just integer-minutes? thanks.
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
> My question is about using spamd to GREYTRAP, but not GREYLIST. > spamd doesn't do that. because it needs to look at the address in order to trap. it does this offline after one delay. It is not written to do instantaneous type trapping, because your MTA can do that. -Bob
Re: using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
hi, > No, that's not what passtime means, and not how spamd works either. > (Read the man page for details; i did read the manual. and have questions. which is why i'm here. > passtime has to do with the time between subsequent connects, *PER* the manual, "After passtime minutes if spamd sees a retried attempt to deliver mail for the same tuple, spamd will whitelist the connecting address by adding it as a whitelist entry to /var/db/spamd." So, If I set passtime to "1 min", then if the sendedr attempts reconnect after that 1 min, it's added to whitelist and spamd is bypassed -- connecting *directly* to the 'real' mail server. my question is about what happens @ passtime *EQUALS* zero. > and using spamd and having people connect > directly to your mail server is mostly mutually exclusive.) once whitelisted, senders ARE directly connected. my point is that I'd like to NOT greylist, but ONLY greytrap. it seems the only options are: (1) BLACKLIST ONLY (2) GREYTRAP & GREYLIST & BLACKLIST can GREYLIST be effectively disabled by by passtime=0? or, can TRAPPING be enabled in blacklist-only mode? > Just use your favourite MTA's blacklisting feature. That's an obvious option. I'm not interested in using the MTA for this. I'm intersted in using spamd @ my edge box to NOT pass traffic to my MTA on another box. My question is about using spamd to GREYTRAP, but not GREYLIST.
using spamd to grey-TRAP *only*, with *no* grey-LIST delays, stutters, etc ?
hi, i'd like to use 'spamd' for GREYTRAPPING only, with NO delay-via-GREYLISTING. i.e., other than mail to defined TRAPS and fully-blacklisted domains, no delay on inbound mmail. looking at config, i think i can achieve that by setting "passtime", via "-Gx:y:z", equal to zero. though it seems straighforward enough, i've never found any reference to such usage. any comments as to whether this'll achieve what i'm hoping for -- or, more importantly, break something? thanks!
