Re: [Exim] SPAM from secondary mail servers that you can not…

Página Inicial
Delete this message
Reply to this message
Autor: Dave C.
Data:  
Para: Vadim Vygonets
CC: exim-users
Assunto: Re: [Exim] SPAM from secondary mail servers that you can not control
On Sun, 27 Jan 2002, Vadim Vygonets wrote:

> Quoth Dave C. on Fri, Jan 25, 2002:
> > On Fri, 25 Jan 2002, Terry Shows wrote:
> > > Does anybody know of a way to search ALL of the "Received:" headers in a
> > > message to see if it originally came from a known spammer, no matter how
> > > many other machines it may have been routed through.
> >
> > Since there is absolutely no standard format for the Received: header
> > this would be very difficult.
>
> Is there no standard format for the Received: header, really?
> RFC 2821, chapter 4.4, verces 1-5, pages 49-50:


Not much there. One "SHOULD", not nearly as strong as "MUST". Some
suggestions as to what information should be included, but nothing
deliniating exactly how it should appear. Any, regardless, even if there
is a standard, there are tons of junk MTA's out there that surely don't
abide by it. Since the probability that these same servers are also the
open relays used by the spammers to send the messge, and the odds that
you have a usefully parseable header decrease signifigantly.

>
> #   When an SMTP server receives a message for delivery or further
> #   processing, it MUST insert trace ("time stamp" or "Received")
> #   information at the beginning of the message content, as discussed in
> #   section 4.1.1.4.
> #
> #   This line MUST be structured as follows:
> #
> #   -  The FROM field, which MUST be supplied in an SMTP environment,
> #      SHOULD contain both (1) the name of the source host as presented
> #      in the EHLO command and (2) an address literal containing the IP
> #      address of the source, determined from the TCP connection.
> #
> #   -  The ID field MAY contain an "@" as suggested in RFC 822, but this
> #      is not required.
> #
> #   -  The FOR field MAY contain a list of <path> entries when multiple
> #      RCPT commands have been given.  This may raise some security
> #      issues and is usually not desirable; see section 7.2.

>
> And there's a formal definition of the Received: header on page
> 52 of the RFC.
>
> Vadik.
>
> --
> Strange Fruit.  A brilliant way to describe
> somebody hanging from a tree...
>         -- Marcus Miller

>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
>


--