PHWinfo - Afficher un message

31/03/2008, 10h59

David F. Skoll wrote:

> > I too dislike the idea of using MIMEDefang or any other milter or
> > external process for the task. Just because it is an external process,
> > while for example exim does this within the MTA itself.

> > The same can be said about other tasks which sendmail cannot do
> > without an external er, like SPF checking, call ahead, antivirus
> > checking etc.

> But that's good design. An MTA should deliver mail. It shouldn't be
> cluttered with policy tools like content scanners, SPF checking, etc.
> It should have hooks for those tools, to be sure, but shouldn't include
> them in its own code.

I think you misunderstood me. For example exim does not include
content scanners in its own code. However, using content scanners, SPF
checking etc in exim does not involve running a bunch of ancillary
processes, which is the case with sendmail.

BTW what is your opinion on DNSBL lookups? Should a well designed MTA
include them in its own code?

> > I have been told several times that the sendmail.cf language is so
> > powerful you can do anything with it. Yet it cannot even do the
> > removal of headers.

> Removal of headers is considered bad because it hampers diagnosing routing
> problems. It also gains you practically no security, so the
> Sendmail authors did not provide for header removal. If you really
> need it, a simple milter is the best way to do it.

Why doesn't this surprise me?

> Please be aware of this clause in RFC 2821:

> 3.8.2 Received Lines in Gatewaying

> When forwarding a message into or out of the Internet environment, a
> gateway MUST prepend a Received: line, but it MUST NOT alter in any
> way a Received: line that is already in the header.

This is a different issue which should be addressed to the OP.
However, I vaguely remember some firewall products which remove
certain fields from outbound E-mail and even HTTP requests. Perhaps it
makes sense under certain circumstances. And I cannot think of any
good use of the private Received: headers to the outsider.

--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

31/03/2008, 10h59	#7
Victor Sudakov Messages: n/a Hébergeur:	Re: Remove Internal Hops from Header David F. Skoll wrote: > > I too dislike the idea of using MIMEDefang or any other milter or > > external process for the task. Just because it is an external process, > > while for example exim does this within the MTA itself. > > The same can be said about other tasks which sendmail cannot do > > without an external er, like SPF checking, call ahead, antivirus > > checking etc. > But that's good design. An MTA should deliver mail. It shouldn't be > cluttered with policy tools like content scanners, SPF checking, etc. > It should have hooks for those tools, to be sure, but shouldn't include > them in its own code. I think you misunderstood me. For example exim does not include content scanners in its own code. However, using content scanners, SPF checking etc in exim does not involve running a bunch of ancillary processes, which is the case with sendmail. BTW what is your opinion on DNSBL lookups? Should a well designed MTA include them in its own code? > > I have been told several times that the sendmail.cf language is so > > powerful you can do anything with it. Yet it cannot even do the > > removal of headers. > Removal of headers is considered bad because it hampers diagnosing routing > problems. It also gains you practically no security, so the > Sendmail authors did not provide for header removal. If you really > need it, a simple milter is the best way to do it. Why doesn't this surprise me? > Please be aware of this clause in RFC 2821: > 3.8.2 Received Lines in Gatewaying > When forwarding a message into or out of the Internet environment, a > gateway MUST prepend a Received: line, but it MUST NOT alter in any > way a Received: line that is already in the header. This is a different issue which should be addressed to the OP. However, I vaguely remember some firewall products which remove certain fields from outbound E-mail and even HTTP requests. Perhaps it makes sense under certain circumstances. And I cannot think of any good use of the private Received: headers to the outsider. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/