Mailinglist Archive: opensuse (4237 mails)

< Previous Next >
Re: [SLE] Fetchmail Daemon Problem
  • From: "Carlos E. R." <robin1.listas@xxxxxxxxxx>
  • Date: Mon, 2 Aug 2004 02:23:40 +0200 (CEST)
  • Message-id: <Pine.LNX.4.58.0408020140160.6646@xxxxxxxxxxxxxxxx>

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

< Previous Next >
References