You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
(21) |
Sep
(17) |
Oct
(35) |
Nov
(39) |
Dec
(55) |
| 2006 |
Jan
(70) |
Feb
(11) |
Mar
(55) |
Apr
(27) |
May
(73) |
Jun
(47) |
Jul
(63) |
Aug
(27) |
Sep
(52) |
Oct
(39) |
Nov
(87) |
Dec
(15) |
| 2007 |
Jan
(23) |
Feb
(46) |
Mar
(108) |
Apr
(63) |
May
(54) |
Jun
(34) |
Jul
(29) |
Aug
(103) |
Sep
(46) |
Oct
(69) |
Nov
(29) |
Dec
(17) |
| 2008 |
Jan
(45) |
Feb
(32) |
Mar
(25) |
Apr
(17) |
May
(39) |
Jun
(20) |
Jul
(64) |
Aug
(31) |
Sep
(38) |
Oct
(20) |
Nov
(42) |
Dec
(50) |
| 2009 |
Jan
(10) |
Feb
(38) |
Mar
(3) |
Apr
(29) |
May
(41) |
Jun
(31) |
Jul
(21) |
Aug
(53) |
Sep
(49) |
Oct
(26) |
Nov
(28) |
Dec
(15) |
| 2010 |
Jan
(83) |
Feb
(38) |
Mar
(33) |
Apr
(44) |
May
(9) |
Jun
(16) |
Jul
(35) |
Aug
(38) |
Sep
(11) |
Oct
(35) |
Nov
(68) |
Dec
(19) |
| 2011 |
Jan
(16) |
Feb
(69) |
Mar
(42) |
Apr
(54) |
May
(56) |
Jun
(29) |
Jul
|
Aug
(65) |
Sep
(3) |
Oct
(39) |
Nov
(33) |
Dec
(4) |
| 2012 |
Jan
(31) |
Feb
(21) |
Mar
(26) |
Apr
(13) |
May
(38) |
Jun
(39) |
Jul
(14) |
Aug
(31) |
Sep
(8) |
Oct
(32) |
Nov
(12) |
Dec
(16) |
| 2013 |
Jan
(40) |
Feb
(22) |
Mar
(21) |
Apr
(15) |
May
(13) |
Jun
(9) |
Jul
(34) |
Aug
(10) |
Sep
(10) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2014 |
Jan
(25) |
Feb
(9) |
Mar
(8) |
Apr
(12) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(27) |
Oct
(25) |
Nov
(18) |
Dec
(3) |
| 2015 |
Jan
(18) |
Feb
(13) |
Mar
(4) |
Apr
(19) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(4) |
Nov
(19) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(8) |
Mar
(14) |
Apr
|
May
(11) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(11) |
Dec
(17) |
| 2017 |
Jan
(17) |
Feb
(35) |
Mar
|
Apr
(4) |
May
(8) |
Jun
(2) |
Jul
(16) |
Aug
|
Sep
(5) |
Oct
(11) |
Nov
(15) |
Dec
(10) |
| 2018 |
Jan
|
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(10) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
| 2019 |
Jan
(4) |
Feb
(14) |
Mar
(33) |
Apr
(17) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(22) |
Oct
(13) |
Nov
|
Dec
|
| 2020 |
Jan
(36) |
Feb
(19) |
Mar
(31) |
Apr
(2) |
May
(22) |
Jun
(7) |
Jul
(25) |
Aug
(9) |
Sep
(17) |
Oct
(52) |
Nov
(13) |
Dec
(9) |
| 2021 |
Jan
(23) |
Feb
(13) |
Mar
(9) |
Apr
(15) |
May
(3) |
Jun
(7) |
Jul
(4) |
Aug
(23) |
Sep
(3) |
Oct
(8) |
Nov
(28) |
Dec
(9) |
| 2022 |
Jan
(38) |
Feb
(2) |
Mar
(56) |
Apr
(24) |
May
(29) |
Jun
(22) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(2) |
Dec
|
| 2023 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2024 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2025 |
Jan
(7) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(10) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
(24) |
Nov
(15) |
Dec
(3) |
| 2026 |
Jan
(7) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(5) |
Jul
(7) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James M. <ji...@so...> - 2004-07-21 19:14:20
|
Hello, fetchmail release 6.2.4+SSL+NLS I have fetchmail forward mail to a bayseian mail classifier, assp (anti-spam smtp proxy). One of assp's features is to block messages with executable attachments. If one is found, it rejects the message and returns an status code of 500 to the sender (fetchmail). Apparently assp closes the connection after returning the error message since signal 13 (broken pipe) is raised in fetchmail. At which time fetchmail terminates. It looks like this happens on the *next* connection attempt with assp. What is more worrisome is that just before the abort, fetchmail says the message was flushed, implying a lost message. Is there some way to have fetchmail re-connect with assp rather than abort? fetchmail: reading message moe...@lo...:2 of 2 (42695 octets) fetchmail: SMTP error: 500 Executable attachments are not allowed -- Compress before mailing. fetchmail: SMTP listener refused delivery fetchmail: flushed fetchmail: 1 message for cherie at localhost (5458 octets). fetchmail: reading message ch...@lo...:1 of 1 (5458 octets) fetchmail: flushed fetchmail: terminated with signal 13 -- jimoe at sohnen-moe dot com |
|
From: Rob F. <rf...@fu...> - 2004-07-21 19:13:45
|
Laurence wrote: > I transferred to berlios from the ccil list a couple of days ago to get > away from the "esr virus-removed" spam and already I've had a Nigerian > spam and one from some Chinese dude via the list. Is there any spam > checking on this list? Maybe sign ups should be approved by a > moderator? Sorry about that. I just changed it to members-only posting, which should help a lot. Since joining the list requires confirmation, I doubt spammers will bother. If they do, I'll have to consider moderating subscriptions. > Maybe I should transfer back to ccil?! Hey, maybe you can talk them into giving you admin access. :-) -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Laurence <lj...@hb...> - 2004-07-21 18:10:32
|
I transferred to berlios from the ccil list a couple of days ago to get away from the "esr virus-removed" spam and already I've had a Nigerian spam and one from some Chinese dude via the list. Is there any spam checking on this list? Maybe sign ups should be approved by a moderator? Looking back through the archives on berlios: 4 messages are spam 1 message is real Maybe I should transfer back to ccil?! Laurence |
|
From: John F. <jo...@mi...> - 2004-06-21 18:32:05
|
I use fetchmail 6.2.3 passing mail onto postfix via smtp. Occasionally, I get a malformed email in my isp mailbox with an envelope from address like this peter@61.172.247.54. That is unacceptable to postfix which gives a 501 response straight after MAIL FROM This is part of the SMTP session: In: MAIL FROM:<peter@61.172.247.54> SIZE=240722 Out: 501 Bad address syntax In: RSET Out: 250 Ok However the mail stays on the pop server and mail just piles up there until I enter and cancel it manually. Once I cancel that mail, everything proceeds ok. I'm not interested in the contents of the message (it originates from a worm) but I don't like the need for manual intervention to get things unblocked. This is what fetchmail logs Jun 21 18:18:47 turate fetchmail[1145]: 1 message for isp...@ng... at pop.ngi.it (240722 octets). Jun 21 18:18:47 turate fetchmail[1145]: reading message isp...@ng...@pop.ngi.it:1 of 1 (240722 octets) Jun 21 18:18:48 turate fetchmail[1145]: flushed Jun 21 18:18:48 turate fetchmail[1145]: client/server protocol error while fetching from pop.ngi.it Jun 21 18:18:48 turate fetchmail[1145]: Query status=4 (PROTOCOL) Jun 21 18:18:56 turate fetchmail[1145]: sleeping at Mon Jun 21 18:18:56 2004 Here's fetchmailrc set daemon 300 set postmaster fet...@mi... set no bouncemail set no spambounce set syslog poll "pop.ngi.it" protocol pop3 interval 1 no envelope username "isp...@mu..." password "xxxxxxx" is loc...@mi... here fetchall smtphost mail.michaweb.net antispam 501 Any ideas while fetchmail cannot delete the message? Thanks, John |