Mailinglist Archive: opensuse (4237 mails)

< Previous Next >
Re: [SLE] Fetchmail Daemon Problem
  • From: "Lorenzo Maldonado M." <sist.mex@xxxxxxxxxxx>
  • Date: Mon, 2 Aug 2004 16:10:30 -0500
  • Message-id: <20040802210924.7CE044FCDB@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The mail server was rejecting this mails with the header filter, and now it is
solved! sorry!

Lorenzo.

On Sunday 01 August 2004 19:23, you wrote:
> The Saturday 2004-07-31 at 20:05 -0500, Patrick Shanahan wrote:
> > > You can use the headers_checks in either case, with a trick. Or,
> > > better, I think, the "access" file (less cpu, acts earlier):
> >
> > agree that 'access' is probably a better choice for the reason you
> > present. Header_checks would be better for a string in 'subject' or
> > other part of the header other than a 'From:' address.
>
> Exactly. But previously I also used header-checks.
>
> > > # rules to reject unwanted email
> > > Mailer-Daemon@xxxxxxxxxxxxxxxxxxxxxxxx REJECT Blocking backscatter
> > > mail from virus scanners
> >
> > the chars after REJECT are comments ??
>
> No, they are given back as a reject reason in the smtp dialog - in my
> case, to fetchmail, otherwise, to whatever is at the other side. See the
> logs:
>
> Jun 18 12:02:09 nimrodel fetchmail[4865]: SMTP> MAIL
> FROM:<MAILER-DAEMON@xxxxxxxxxxxxxxxx> SIZE=43906 Jun 18 12:02:09 nimrodel
> fetchmail[4865]: SMTP< 250 Ok
> Jun 18 12:02:09 nimrodel fetchmail[4865]: SMTP> RCPT TO:<cer@localhost>
> Jun 18 12:02:09 nimrodel postfix/smtpd[4938]: NOQUEUE: reject: RCPT from
> localhost[127.0.0.1]: 554 <MAILER-DAEMON@xxxxxxxxxxxxxxxx>: Sender address
> rejected: Blocking backscatter mail from virus scanners;
> from=<MAILER-DAEMON@xxxxxxxxxxxxxxxx> to=<cer@localhost> proto=ESMTP
> helo=<localhost> Jun 18 12:02:09 nimrodel fetchmail[4865]: SMTP< 554
> <MAILER-DAEMON@xxxxxxxxxxxxxxxx>: Sender address rejected: Blocking
> backscatter mail from virus scanners Jun 18 12:02:09 nimrodel
> fetchmail[4865]: SMTP error: 554 <MAILER-DAEMON@xxxxxxxxxxxxxxxx>: Sender
> address rejected: Blocking backscatter mail from virus scanners Jun 18
> 12:02:09 nimrodel fetchmail[4865]: SMTP listener doesn't like recipient
> address `cer@localhost'
>
>
> Then fetchmail tries to send back a reject message - it has to, of course,
> because it can not talk back to the original smtp sender, that would have
> to be done by the pop3 server. But I don't allow fetchmail to send that
> reject message, because an "access" rule affects both sender and
> destination addresses:
>
>
> Jun 18 12:02:09 nimrodel fetchmail[4865]: SMTP> RCPT
> TO:<postmaster@localhost> Jun 18 12:02:09 nimrodel postfix/smtpd[4938]:
> NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 554
> <MAILER-DAEMON@xxxxxxxxxxxxxxxx>: Sender address rejected: Blocking
> backscatter mail from virus scanners; from=<MAILER-DAEMON@xxxxxxxxxxxxxxxx>
> to=<postmaster@localhost> proto=ESMTP helo=<localhost> Jun 18 12:02:09
> nimrodel fetchmail[4865]: SMTP< 554 <MAILER-DAEMON@xxxxxxxxxxxxxxxx>:
> Sender address rejected: Blocking backscatter mail from virus scanners Jun
> 18 12:02:09 nimrodel fetchmail[4865]: can't even send to postmaster!
>
> ┬┐See? Its funny seeing fetchmail in distress ;-)
>
>
> By the way, I took the sentence "Blocking backscatter mail from virus
> scanners" from the postfix site. The problem is that some sites have virus
> scanners that reject viruses, sending back to the apparent originator
> (which is faked, of course) the received email, complete with the virus
> load intact. Very "nice" of them, they are compounding the problem: that's
> backscatter mail.
>
> You see the whole conversation takes one second; unfortunately, fetchmail
> (or the pop3 server) takes some time before moving on to the next message
> (and time, with a modem, is money):
>
> Jun 18 12:02:10 nimrodel fetchmail[4865]: SMTP> RSET
> Jun 18 12:02:10 nimrodel fetchmail[4865]: SMTP< 250 Ok
> Jun 18 12:02:21 nimrodel fetchmail[4865]: flushed
> Jun 18 12:02:21 nimrodel fetchmail[4865]: POP3> DELE 75
> Jun 18 12:02:21 nimrodel fetchmail[4865]: POP3< +OK message marked for
> deletion Jun 18 12:02:21 nimrodel fetchmail[4865]: POP3> RETR 76
>
>
> The delay is not due to the problem I reported with SuSE 9.1, because this
> particular log entry belongs to SuSE 8.2 - no, now that I think, it will
> be because fetchmail is trying to send back the whole original email! It
> is also a backscatter originator :-(
>
> Cute problem, backscatter email...
>
> > > # This rule redirects email sent by _my_ fetchmail. If I don't do this,
> > > # for every reject (above) fetchmail will send another email explaining
> > > # the reject.
> > > FETCHMAIL-DAEMON@xxxxxxxxxxxxxxxx REDIRECT virusalert@localhost
> >
> > You do this in 'access' ?? or in virtual ????
>
> In access as well, yes. Redirect is a new addition, I wanted to use it.
> Virtual... well, perhaps :-?
>
> Ah, no, I used it because an "access" rule works even for a match on the
> "From" part, thus triggering when fetchmail sends email. I forgot to
> document it O:-)
>
> > > I also have script to process email sent to virusalert and create logs
> > > instead.
> >
> > Procmail ??
>
> Right. :-)
>
> A quick hack:
> :0
>
> * ^From.*FETCHMAIL-DAEMON@xxxxxxxxxxxxxxxx
> {
>
> :0 c
>
> $HOME/Mail/root/in_fetchmail
>
> :0
> :
> | cat > $HOME/bin/pfb.input ; $HOME/bin/pfb
>
> }
>
>
> Then I parse that email using the script HOME/bin/pfb. I don't like that
> 'cat' there, but it works.
>
> That reminds me, I have to revise it, something has changed when I
> upgraded and some info is missing from the log I generate.
>
> --
> Cheers,
> Carlos Robinson

- --
Lorenzo Maldonado M.
Ovoplus del Centro S.A. de C.V.
Tel/Fax: 55872707
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDq3Gv7QrazZAdS0RAvNNAJwMRTzJuF67nEmeXXRtBwdkZE75NgCgsDkF
u6OkJ/DgWXNQfQNn8LU2aiM=
=/1fK
-----END PGP SIGNATURE-----

< Previous Next >