/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
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.

Søg
Reklame
Statistik
Spørgsmål : 177557
Tips : 31968
Nyheder : 719565
Indlæg : 6408872
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste