Re: [milter-greylist] SMTP auth and greylisting
2005-03-16 by manu@netbsd.org
... Seems you are going to do add a few printf inside milter-greylist to discover what is going on. in milter-greylist.c, search for Is the user
Messages
Browse messages
Page 122 of 144 · 7199 messages matched
Re: [milter-greylist] timeouts
2005-03-16 by Steven Stern
... I ve doubled the timeout values and will check the logs tomorrow: INPUT_MAIL_FILTER(`greylist ,
Re: [milter-greylist] timeouts
2005-03-16 by Emmanuel Dreyfus
... No, it s not a bug. Increase the timeout in sendmail.cf and it will disapear. -- Emmanuel Dreyfus manu@netbsd.org
Re: [milter-greylist] timeouts
2005-03-16 by Steven Stern
... That must be it. Thanks. Is this on the to-do list for 2.0? -- Steve
Re: [milter-greylist] SMTP auth and greylisting
2005-03-16 by BERTRAND Joël
... Matthieu, I have in my sendmail.cf : O Milter.macros.envfrom=i, {auth_type}, {auth_authen}, {auth_ssf}, {auth_author}, {mail_mailer}, {mail_host},
Re: [milter-greylist] timeouts
2005-03-16 by manu@netbsd.org
... Do you use SPF? You get this when it times out because of DNS requests. -- Emmanuel Dreyfus Un bouquin en français sur BSD:
timeouts
2005-03-16 by Steven Stern
Using milter-greylist 2.0b2 on Fedora Core 3 From this morning s logwatch report: Milter (greylist): timeout before data read: 15 Time(s) Milter (greylist): to
Re: [milter-greylist] SMTP auth and greylisting
2005-03-15 by Matthieu Herrb
... Yes. That s what I meant. But after looking at the code, it seems unlikely. Better start by double-checking that ${auth_authen} is passed to
Re: [milter-greylist] re: Delay calculation
2005-03-15 by Emmanuel Dreyfus
... I cat several files to overwrite my config at the moment. If we do an include option, I think it would be nice to have the ability to include remote files.
Re: [milter-greylist] re: Delay calculation
2005-03-15 by Matthias Scheler
... 4) Add a include feature to the configuration parser which would make 3) a lot easier because one could simply overwrite the file with the automatically
Re: [milter-greylist] 2.0b2 - domain acl's not working?
2005-03-15 by manu@netbsd.org
... Oh yes, it s emitted through yyerror instead of syslog. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
Re: [milter-greylist] re: Delay calculation
2005-03-15 by manu@netbsd.org
... Centralized whitelist would be a nice feature. I see two ways of implementing that in milte-rgreylist: 1) URL inclusion: you d say in greylist.conf that
Re: [milter-greylist] re: Delay calculation
2005-03-15 by Joseph Burford
Alan, ... I currently maintain a whitelist for my own use, a couple of other people use it and provide info for it. http://www.ntjl.net/whitelist/ It s fairly
re: Delay calculation
2005-03-14 by Alan Clifford
... That moves the subject away from the original subject but no matter - it is interesting. It does seem sensible but I wouldn t want to get into maintaining
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Ethan Burnside
Uriel, ... I didn t read much past that. This is a list for people that run mail servers. You don t go to Spain and expect everyone to speak German, nor do
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Uriel Wittenberg
... It might help if you d read a bit more carefully. I referred to spelling errors PLUS SEMANTIC OBSCURITY. Is this a quibble? Not at all. The trouble with
Re: [milter-greylist] SMTP auth and greylisting
2005-03-14 by manu@netbsd.org
... You mean milter-greylist would be confused because the client would use both STARTTLS and SMTP AUTH afterwards? -- Emmanuel Dreyfus Le cahier de l admin
Re: [milter-greylist] SMTP auth and greylisting
2005-03-14 by Matthieu Herrb
... May be there s some incompatiblity in the current code between using STARTTLS with a client certificate and just using it to send SMTP AUTH over a secured
Re: [milter-greylist] SMTP auth and greylisting
2005-03-14 by manu@netbsd.org
... It seems nobody can answers this question. Matthieu, you contributed the STARTTLS support, maybe you ll have a hint? -- Emmanuel Dreyfus Le cahier de
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by manu@netbsd.org
... I suspect it s because I wrongly assumed you had some knowledge in the field of internet mail. If you need some background, here is a paper on the subject:
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by A. Garth Brook
... Here he means the sending server, so yeah an intermediate sender if you will. It is much better for the sending server to be
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Uriel Wittenberg
I m sorry to tell you your messages are hopelessly obscure. This is no way to communicate. And your copious spelling errors aren t any help either. If your
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Emmanuel Dreyfus
... You can t know if it s forget or not without trying to send a message. This is why most of the time filtering at the SMTP connexion time is prefered. The
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Uriel Wittenberg
... ?? I thought the point of sending a notification to a black-listed sender was to warn him in case he s actually LEGIT. If the sender address is forged, why
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Emmanuel Dreyfus
... Because at that time, you accepted the message, and the only way to send a notification is to trust the sender address. And you know this is forged most of
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-14 by Uriel Wittenberg
... Why is notification impossible when deleting previously accepted messages as I suggested? Why not: - ISP receives a message for user - sender address
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-12 by manu@netbsd.org
... Because in the scenario you described, your blacklist is supposed to be updated within one hour. That s why I assumed it was a DNSRBL-style blacklist, or
Re: [milter-greylist] Delay calculation
2005-03-12 by manu@netbsd.org
... The right way of dealing with mail farms is to whitelist them. A message coming from Google pool will always hit your mailbox, regardless if it is spam or
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-12 by Uriel Wittenberg
... Excuse me, but ARE ALL BLACKLISTS UNRELIABLE? That s what you re suggesting. I never talked about DNSRBL s, and I have no idea why you keep harping on
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-12 by manu@netbsd.org
... Because you can never be sure a DNSRBL is reliable. The ISP suspects the message is spam, should the mail be deleted? Deleting e-mail is bad because it
Re: [milter-greylist] Delay calculation
2005-03-12 by Alan Clifford
... Thanks for the explanation. I wouldn t like to comment on the message-id proposal as I haven t had much experience using greylisting yet. Or maybe I
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-12 by Uriel Wittenberg
... Why should I have to download spam which my ISP knows is spam?? My ISP should continually delete items it discovers to be spam BEFORE I ever waste my time
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-12 by manu@netbsd.org
... DNS Reverse Black List ... I think your idea is good, but it s the kind of filtering I d rather see at the MUA (Mail User Agent, outlook express in your
Re: Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-12 by Uriel Wittenberg
... To be totally frank ......... I have no clue what a DNSRBL is. I was just looking for a simple acknowledgment that no one here has yet provided. Your
Re: [milter-greylist] Delay calculation
2005-03-12 by manu@netbsd.org
... Usually, this is caused by that: Mail A arrives from (IP, from, rcpt) at time t Mail B arrives from (IP, from, rcpt) at time t+23 Mail A arrives from (IP,
Delay calculation
2005-03-12 by Alan Clifford
After a couple of days, this seems to be the magic bullet. I hope it lasts. The delay reported on the message below appears to be over 23 hours but
Re: [milter-greylist] Why the use of basic regexes instead of extended?
2005-03-11 by Matt Kettler
... Ahh, I can do that too. I ll look at writing it this weekend, spare time permitting.
Re: [milter-greylist] Why the use of basic regexes instead of extended?
2005-03-11 by manu@netbsd.org
... Well I meant a patch adding a config file option... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
Re: [milter-greylist] Why the use of basic regexes instead of extended?
2005-03-11 by Matt Kettler
... Sure.. it s quite trivial anyway.. See attached diff -u patch. By the way, if you ve got the patch, the following ACL will greylist hosts which are
Re: [milter-greylist] Why the use of basic regexes instead of extended?
2005-03-11 by manu@netbsd.org
... No real reason. Would you like to contribute a patch for a reg_extended flag in the config file? That s an easy one. -- Emmanuel Dreyfus Publicité
Re: [milter-greylist] Re: Use real-time black lists *retroactively*!
2005-03-11 by manu@netbsd.org
... Well I do use a blacklist, but it s a manual one. I blacklist the netblocks for which I still get spam and for which no abuse address works. I assumed you
Re: Use real-time black lists *retroactively*!
2005-03-11 by Uriel Wittenberg
... The passage I quoted from http://hcpnet.free.fr/milter-greylist/ assumes use of a black list. I m simply proposing a fuller and more sensible use. If a
Why the use of basic regexes instead of extended?
2005-03-11 by Matt Kettler
Question, is there a reason the regcomp calls in acl.c do not use the REG_EXTENDED flag? I m kind of used to modern extended regex syntax including things like
Re: [milter-greylist] Use real-time black lists *retroactively*!
2005-03-11 by Emmanuel Dreyfus
... Interesting idea, but 1) black lists are not reliable 2) your idea woks only if the mail is hold on the mail server. What if it has been forwarded to
Use real-time black lists *retroactively*!
2005-03-11 by Uriel Wittenberg
Why don t ISP s use real-time black lists *retroactively* to eliminate PENDING spam? What I mean is, in the following scenario.... ... NOON: Spam item Z from
exact match for rcpt/from/domain
2005-03-11 by manu@netbsd.org
Problem: rcpt/from/domain rules currently perform a substring match. For instance if you write acl whitelist x@example.com This will match xx@example.com.
Re: [milter-greylist] 2.0b2 - domain acl's not working?
2005-03-10 by Matt Kettler
... Mar 9 19:19:07 xanadu milter-greylist: config error at line 281: parse error For some reason, those, along with the startup and shutdown messages are
Re: [milter-greylist] 2.0b2 - domain acl's not working?
2005-03-10 by manu@netbsd.org
... What is the message? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
Re: [milter-greylist] 2.0b2 - domain acl's not working?
2005-03-10 by Matt Kettler
... Ugh! I found the problem.. Unfortunately, the message I needed was being logged to /var/log/messages instead of /var/log/maillog. I ve got a typo in the
Re: [milter-greylist] 2.0b2 - domain acl's not working?
2005-03-09 by Matt Kettler
... I sent you an off-list message with it. Also of note: adding non-regex domain ACLs works fine... adding regex based rcpt rules works fine... adding address