|
| Mail loops og virusfiltrering Fra : Jesper Harder |
Dato : 02-07-02 17:17 |
|
Jeg filtrerer mails sendt til en af mine konti med procmail ved at
starte procmail fra min .forward fil.
Mit procmail-script slår op i ORDB m.fl. og indsætter en passende ekstra
header. Til sidst bliver alle mails sendt videre til en konto hos TDC
med:
:0
! harder@c.dk
Der er så sket det, at TDC er begyndt at virusscanne indkommende emails,
hvilket resulterer i en mail loop -- en Klez virus jeg får tilsendt
bliver sendt frem og tilbage 2-3 gange i minuttet i løbet af nogle dage
(ca. 7000-8000 gange i alt) og mailen vokser sig større og større (over
400.000 linjer). Til sidst er den ene server ved at gå i knæ, og den
lokale sysadmin stopper løkken.
Spørgsmålet er så, hvis fejl det er:
* TDC's MTA?
* Sendmail på da401.ifa.au.dk?, eller
* Er det ens eget ansvar at tjekke for den situation i procmailrc?
Her er en lille udsnit af mailen:
--IAA17922.1025419541/da401.ifa.au.dk
Content-Type: message/rfc822
Return-Path: <harder>
Received: (from harder@localhost)
by da401.ifa.au.dk (8.9.3/8.9.3) id IAA03042
for harder@c.dk; Sun, 30 Jun 2002 08:45:36 +0200 (MET DST)
Received: from localhost (localhost)
by da401.ifa.au.dk (8.9.3/8.9.3) with internal id IAA20931;
Sun, 30 Jun 2002 08:45:35 +0200 (MET DST)
Date: Sun, 30 Jun 2002 08:45:35 +0200 (MET DST)
From: Mail Delivery Subsystem <MAILER-DAEMON>
Message-Id: <200206300645.IAA20931@da401.ifa.au.dk>
To: harder
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="IAA20931.1025419535/da401.ifa.au.dk"
Subject: Returned mail: Service unavailable
Auto-Submitted: auto-generated (failure)
This is a MIME-encapsulated message
--IAA20931.1025419535/da401.ifa.au.dk
The original message was received at Sun, 30 Jun 2002 08:45:30 +0200 (MET DST)
from harder@localhost
----- The following addresses had permanent fatal errors -----
harder@c.dk
----- Transcript of session follows -----
.... while talking to smtp.mail.dk.:
>>> DATA
<<< 550 Error: Infected by Klez virus
554 harder@c.dk... Service unavailable
--IAA20931.1025419535/da401.ifa.au.dk
Content-Type: message/delivery-status
Reporting-MTA: dns; da401.ifa.au.dk
Arrival-Date: Sun, 30 Jun 2002 08:45:30 +0200 (MET DST)
Final-Recipient: RFC822; harder@c.dk
Action: failed
Status: 5.2.0
Remote-MTA: DNS; smtp.mail.dk
Diagnostic-Code: SMTP; 550 Error: Infected by Klez virus
Last-Attempt-Date: Sun, 30 Jun 2002 08:45:35 +0200 (MET DST)
--IAA20931.1025419535/da401.ifa.au.dk
Content-Type: message/rfc822
Return-Path: <harder>
Received: (from harder@localhost)
by da401.ifa.au.dk (8.9.3/8.9.3) id IAA14178
for harder@c.dk; Sun, 30 Jun 2002 08:45:30 +0200 (MET DST)
Received: from Ufmridox (pool-141-151-11-193.phil.east.verizon.net [141.151.11.193])
by da401.ifa.au.dk (8.9.3/8.9.3) with SMTP id IAA24023
for <harder@ifa.au.dk>; Sun, 30 Jun 2002 08:45:13 +0200 (MET DST)
Date: Sun, 30 Jun 2002 08:45:13 +0200 (MET DST)
Message-Id: <200206300645.IAA24023@da401.ifa.au.dk>
From: techsupport <techsupport@mcafee.com>
To: harder@ifa.au.dk
Subject: Printer Sharing).
MIME-Version: 1.0
| |
Ole Michaelsen (02-07-2002)
| Kommentar Fra : Ole Michaelsen |
Dato : 02-07-02 17:58 |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesper Harder wrote:
> Spørgsmålet er så, hvis fejl det er:
>
> * TDC's MTA?
> * Sendmail på da401.ifa.au.dk?, eller
> * Er det ens eget ansvar at tjekke for den situation i procmailrc?
Jeg vil meme at du, inden du sender brevet videre til din konto hos TDC,
boer indsaette en X-header, og saa ikke udfoere videresendingen, hvis
denne header findes i forvejen (dvs hvis brevet afvises og
tilbagesendes fra TDC). Paa den maade undgaar du mailloop.
Det kan goeres med formail.
VH,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9Idt6isVFpq+NLzsRAlRXAJ44bX+iVu7h4JsXp6ULUwDnRL1TkwCgltki
QP2BtEg61SIK9SxZU1YilWI=
=owmM
-----END PGP SIGNATURE-----
--
Ole Michaelsen, Darmstadt, Germany
http://www.fys.ku.dk/~omic
| |
Allan Olesen (02-07-2002)
| Kommentar Fra : Allan Olesen |
Dato : 02-07-02 18:47 |
|
Jesper Harder <harder@myrealbox.com> wrote:
>Spørgsmålet er så, hvis fejl det er:
Det kan du spekulere længe og inderligt over, og du kan måske
endda i nogle tilfælde få ret i, at det er andres fejl[1]. Men du
kan også vælge den lidt mere pragmatiske løsning:
- Indsæt en ekstra header i alle de mails, du forwarder.
- Check for tilstedeværelsen af denne header - både i headere
og body - inden du forwarder.
Den indsatte header skal være unik i den forstand, at du gerne må
indsætte samme header i alle mails, men du skal gøre den så
personlig, at ingen andre finder på at indsætte samme header.
Det burde beskytte dig, ikke kun mod TDC's virusfilter, men også
mod de fleste andre tilfælde af forwarding-mailloops.
Derudover kan det også være en god ide at lade være med at
forwarde mails fra postmaster eller MAILER-DAEMON, eller mails
med headeren
Content-Type: message/delivery-status
men det kræver naturligvis, at du også læser post på den konto,
der forwardes fra.
[1]: Jeg mener personligt, at det er småtåbeligt (men meget
udbredt) at sende vedhæng med retur i en bounce-meddelelse, og
hamrende tåbeligt at sende dem med retur i en virusadvarsel. Man
kan så argumentere for, at ingen af de to mailservere gør
sidstnævnte, men au's server gør i hvert fald førstnævnte.
--
Allan
| |
Jesper Harder (02-07-2002)
| Kommentar Fra : Jesper Harder |
Dato : 02-07-02 22:16 |
|
Allan Olesen <aolesen@post3.tele.dk> writes:
> Jesper Harder <harder@myrealbox.com> wrote:
>
>>Spørgsmålet er så, hvis fejl det er:
>
> Det kan du spekulere længe og inderligt over, og du kan måske
> endda i nogle tilfælde få ret i, at det er andres fejl[1].
Det har jeg så spekuleret lidt over ... og er kommet frem til at MTA'en
hos ifa.au.dk laver en fejl. RFC 2821 siger utvetydigt at bouncen
*skal* sendes med en tom reverse-path, hvilket den ikke bliver:
This notification message must be from the SMTP server at the relay
host or the host that first determines that delivery cannot be
accomplished. Of course, SMTP servers MUST NOT send notification
messages about problems transporting notification messages. One way
to prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a message
is transmitted the reverse-path MUST be set to null (see section
4.5.5 for additional discussion). A MAIL command with a null
reverse-path appears as follows:
MAIL FROM:<>
> Men du kan også vælge den lidt mere pragmatiske løsning:
Tak, udmærkede forslag.
Men det hjælper jo ikke de andre brugere. Det ville være mærkeligt,
hvis jeg er den eneste som laver forwarding. Så før eller siden vil
problemet jo nok opstå igen, hvis ikke den ansvarlige for den forkerte
sendmail-konfiguration får at vide, at der er et problem.
| |
|
|