Does anybody have a good / solid solution for removing mail hops out
of outbound email when a sendmail MTA is the last hop before talking
to hosts on the internet?

J

welchjh@gmail.com unleashed the infinite monkeys on 28/03/2008 19:40
producing:
> Does anybody have a good / solid solution for removing mail hops out
> of outbound email when a sendmail MTA is the last hop before talking
> to hosts on the internet?

Try searching the archives for this newsgroup where you'll find this has
been discussed dozens (if not hundreds by now) of times.

--
Rob MacGregor (BOFH)

Rule 37: "There is no 'overkill'. There is only 'open fire'
and 'I need to reload.'"

Rob MacGregor wrote:
> > Does anybody have a good / solid solution for removing mail hops out
> > of outbound email when a sendmail MTA is the last hop before talking
> > to hosts on the internet?

> Try searching the archives for this newsgroup where you'll find this has
> been discussed dozens (if not hundreds by now) of times.

Alas, discussed without any result.

I have been able to do this with exim only (a special router with
"headers_remove = received" set). No luck with sendmail.


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

Victor Sudakov unleashed the infinite monkeys on 29/03/2008 07:12 producing:
>
> Alas, discussed without any result.

My memory is that at least one response included the "You could use
MIMEDefang to do this" response, though without providing the details as
to how (probably because they too don't think it's a good idea).

If you were to follow this route it would involve creating a perl filter
to strip out any Received headers, or alter them to remove the data
you're worried about leaking.

--
Rob MacGregor (BOFH)

Rule 37: "There is no 'overkill'. There is only 'open fire'
and 'I need to reload.'"

Rob MacGregor wrote:
> >
> > Alas, discussed without any result.

> My memory is that at least one response included the "You could use
> MIMEDefang to do this" response, though without providing the details as
> to how (probably because they too don't think it's a good idea).

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.

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.

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

Victor Sudakov 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 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.

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.

If you remove an existing Received: line, you may technically be violating
RFC 2821.

Regards,

David.

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/

On 03/30/08 11:35, David F. Skoll wrote:
> 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.

Consider if you will an install that has an SMTP server running with in
each department that forwards to the building / campus SMTP server that
forwards to one (or more) corporate SMTP servers that then forward to
the world. There would *VERY LIKELY* be internal network structure
information exposed that probably should not be exposed.

If you compare an internal SMTP structure to either an Exchange or
GroupWise structure, you will quickly notice (amongst other things) that
SMTP will have additional Received: headers added by each SMTP server.
Where as the Exchange / GroupWise system has no such headers that appear
in the messages that leave the company. I believe it is these headers
that the OP is wanting to remove.

> 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.

I agree to this for gatewaying inbound messages. However outbound
messages do not need to contain internal Received: headers.

> If you remove an existing Received: line, you may technically be
> violating RFC 2821.

Remember that RFCs are good guidelines to be followed with in reason.
Rather RFCs are not the LAW or the BIBLE of networking. I generally try
to follow them unless I have a good reason to deviate from them.



Grant. . . .

Victor Sudakov wrote:

> 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.

How does Exim do it? With shared library plugins? Or does it fork/exec
a subprogram? If the latter, that's vastly *less* efficient than a milter.

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

No. (And indeed, Sendmail does not directly include DNSBL lookups...
they are implemented in its configuration language.)

[...]

> 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.

Received: headers are likely of very little use to the outside, but may
be very useful for insiders who are trying to diagnose mail loop problems.
Since Received: headers are not a security risk (in spite of some "firewall
products" opinions) and may be useful for diagnosing mail problems, you
might as well leave them in.

Regards,

David.

Grant Taylor wrote:

> Consider if you will an install that has an SMTP server running with in
> each department that forwards to the building / campus SMTP server that
> forwards to one (or more) corporate SMTP servers that then forward to
> the world. There would *VERY LIKELY* be internal network structure
> information exposed

So?

> that probably should not be exposed.

Why not? Do you honestly think that pretending your internal network
structure is "secret" will actually hamper anyone?

> If you compare an internal SMTP structure to either an Exchange or
> GroupWise structure, you will quickly notice (amongst other things) that
> SMTP will have additional Received: headers added by each SMTP server.
> Where as the Exchange / GroupWise system has no such headers that appear
> in the messages that leave the company. I believe it is these headers
> that the OP is wanting to remove.

So Sendmail is RFC compliant and Exchange and Groupwise are not. Color
me surprised.

> I agree to this for gatewaying inbound messages. However outbound
> messages do not need to contain internal Received: headers.

.... until the day you have a mail loop and try to diagnose it.

>> If you remove an existing Received: line, you may technically be
>> violating RFC 2821.

> Remember that RFCs are good guidelines to be followed with in reason.
> Rather RFCs are not the LAW or the BIBLE of networking.

Violating a MUST NOT clause of an RFC is pretty drastic. I do not
think you have enough justification for doing it. RFCs are the *only*
documents that ensure interoperability and violating them just for fun
will lead to chaos.

By the way, e-mails I send go from shishi.roaringpenguin.com (192.168.2.3)
to vanadium.roaringpenguin.com (192.168.10.23) to www.roaringpenguin.com
(206.191.13.82) to the Internet. Now that you know my internal network
structure... am I more vulnerable than before?

Regards,

David.

On 3/31/2008 9:51 PM, David F. Skoll wrote:
> So?

*sigh*

If you can not (or chose not) to understand why someone might not want
to expose (some of) their internal network structure via extra Received:
headers, I can not explain it to you.

> Why not? Do you honestly think that pretending your internal network
> structure is "secret" will actually hamper anyone?

If "secret" means not advertising your internal structure, and "anyone"
means more than experienced crackers with a vast tool box all the way
down to script kiddies that drop a .eml file on to a utility, then in a
word "Yes". Is removing extra Received: headers that critical of a
security measure, no. Does it expose some information that would likely
other wise not be exposed, yes. Thus not exposing it does security.

> So Sendmail is RFC compliant and Exchange and Groupwise are not.
> Color me surprised.

Ok, I'll bite and ask. How is Exchange and GroupWise not RFC compliant
when they are running internal protocols (X.400 for Exchange) that (to
the best of my knowledge) do not have the equivalent of Received:
headers. In other words, how are they breaking RFC by not adding
something they do not have. When messages originate internally and go
out to the world, the first header you will see is the first receiving
SMTP server, the one that got it from Exchange / GroupWise. Likewise
the last Received: header you will see on an inbound message is the edge
SMTP gateway. Thus these systems have no way to expose internal structure.

Think out side of SMTP.

> ... until the day you have a mail loop and try to diagnose it.

There are ways to detect mail loops other than with Received: headers.

> Violating a MUST NOT clause of an RFC is pretty drastic. I do not
> think you have enough justification for doing it. RFCs are the
> *only* documents that ensure interoperability and violating them just
> for fun will lead to chaos.

Whether the OP or I have enough justification or not is up to us. If we
are willing to remove or never add Received: headers on outbound
messages and deal with the ramifications for doing such (having to
detect mail loops other ways with in our systems) I see no reason why we
can not or should not remove / not add the headers.

Will you please list one or two other reasons (other than "breaking RFC'
and "mail loop detection") why removing / not adding internal Received:
headers is bad?

Yes RFCs are a very strongly suggested guide to inter operate with
others. However I fail to see how not having Received: headers from
internal mail servers will make our systems any less inter operable with
others seeing as how we are speaking the same (E)SMTP that we would as
if the headers were still there.

> By the way, e-mails I send go from shishi.roaringpenguin.com
> (192.168.2.3) to vanadium.roaringpenguin.com (192.168.10.23) to
> www.roaringpenguin.com (206.191.13.82) to the Internet. Now that you
> know my internal network structure... am I more vulnerable than
> before?

Are you more vulnerable? That is tough to say. Presuming that you were
truthful, I do have more information about your internal structure and
information that I would very likely use in an attack (if I did such
things).

Based on the headers from a message you sent me the other day, I'm
deducing / predicting the following:
- ShiShi is your workstation that you sent the emails from. I know
this based on what you have said which agrees with the headers in your
message. You did not do any thing to hide or mis-represent your
Received: headers did you???
- Vanadium is an edge SMTP server that has directly routable access to
the 192.168.2.x network.
- Vanadium is connected to a generic internet connection on the
64.26.171.x network with a extremely generic looking reverse DNS.
- Vanadium is (or did) use www as a smart host, which would make sense
considering the generic looking reverse DNS.

In short, if you (and everyone else in between) are not firewalling for
spoofed packets, chances are good that I could send packets to Vanadium
spoofing ShiShi as the source IP and the replies would end up being
passed in to ShiShi. Can I use this to directly exploit any thing? I'm
not talented enough to say one way or the other. However the point
being that I do already have some information on your internal network
structure. I also have some network ranges to start throwing scans at
to see what will and will not get through. Now you are dependent on a
firewall to stop my traffic. Where as if you had not given the traffic
out in the first place I would be that far behind where I am now.

Oh, ya, WWW is not adding any indication of authentication from
Vanadium. So if I were an energetic spacker, I would be tempted to
analyze the SMTP transaction with WWW so that I could predict the
expected packets. If I can successfully predict the expected packets, I
can possibly send them with the spoofed IP of Vanadium and rely traffic
through your server.

Just think about how much harder it would be for me to exploit your
systems if I did not have any thing other than the Received: header
added by my server indicating that it received the message from www.



Grant. . . .

David F. Skoll wrote:

> > 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.

> How does Exim do it? With shared library plugins?

Yes, SPF check is implemented as a shared library. Some checks like
call ahead are internal. Antivirus and antispam interfaces work via a
Unix socket or TCP socket. What I mean is, with sendmail you must run
a) clamav-milter and b) clamd. With exim you run only clamd.

> Or does it fork/exec
> a subprogram? If the latter, that's vastly *less* efficient than a milter.

Of course, it does not exec any subprograms.

[dd]

> > 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.

> Received: headers are likely of very little use to the outside, but may
> be very useful for insiders who are trying to diagnose mail loop problems.

I rather doubt the insiders will diagnose internal mail loop problems
from the outside. If there is a mail loop within the corporate
network, the mail is unlikely to leave it.

> Since Received: headers are not a security risk (in spite of some "firewall
> products" opinions)

I am not so sure. In fact they can reveal some private, internal
informaion.

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

Victor Sudakov <vas@mpeks.no-spam-here.tomsk.su> wrote:

> David F. Skoll wrote:
>> > [...]
>> > 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.
>
>> Received: headers are likely of very little use to the outside, but may
>> be very useful for insiders who are trying to diagnose mail loop problems.
>
> I rather doubt the insiders will diagnose internal mail loop problems
> from the outside. If there is a mail loop within the corporate
> network, the mail is unlikely to leave it.

The subject states "remove". Removing received: header in full *WILL*
lead to creation of possibility of *nasty* email loops going undetected.
Rewriting "internal" received: headers (removing "private" parts) avoids
*this* risk.
[ Sendmail/MTA counts number of received: headers to *detect* email loops ]

>> Since Received: headers are not a security risk (in spite of some
>> "firewall products" opinions)
>
> I am not so sure. In fact they can reveal some private, internal
> informaion.

Stripping "internal" info from received: headers is not the thing you
should *start* from on your path to improve security. Anyway it makes
*some* sense in "higher security" oriented setups. It makes a lot of
sense in *HIGH* security setups of some computer networks.
I would not like to suggest that sendmail is "unfit" for such setups.

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Likewise, the national appetizer, brine-cured herring with raw onions,
wins few friends, Germans excepted.
-- Darwin Porter "Scandinavia On $50 A Day"

"David F. Skoll" <dfs@roaringpenguin.com> wrote:

> Victor Sudakov 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 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.
>
> 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.
>
> If you remove an existing Received: line, you may technically be violating
> RFC 2821.

*Rewriting* of Received: headers generated by servers under you control
operating on "internal" network:
a) breaks letter of the RFC
b) *IMHO* it does not break spirit of the RFC

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
The knowledge that makes us cherish innocence makes innocence unattainable.
-- Irving Howe

Andrzej Adam Filip wrote:
> >> > 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.
> >
> >> Received: headers are likely of very little use to the outside, but may
> >> be very useful for insiders who are trying to diagnose mail loop
> >> problems.
> >
> > I rather doubt the insiders will diagnose internal mail loop problems
> > from the outside. If there is a mail loop within the corporate
> > network, the mail is unlikely to leave it.

> The subject states "remove". Removing received: header in full *WILL*
> lead to creation of possibility of *nasty* email loops going undetected.

Provided the said headers are removed at the very edge of the network,
not before the message leaves the corporate network, I see no
possibility of loop creation. What is a possible loop scenario in this
setup?

> Rewriting "internal" received: headers (removing "private" parts) avoids
> *this* risk.

But this is equally wrong from the point of view of the RFC which
states: "it MUST NOT alter in any way a Received: line that is already
in the header".


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

Victor Sudakov <vas@mpeks.no-spam-here.tomsk.su> wrote:

> Andrzej Adam Filip wrote:
>> >> > 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.
>> >
>> >> Received: headers are likely of very little use to the outside, but may
>> >> be very useful for insiders who are trying to diagnose mail loop
>> >> problems.
>> >
>> > I rather doubt the insiders will diagnose internal mail loop problems
>> > from the outside. If there is a mail loop within the corporate
>> > network, the mail is unlikely to leave it.
>
>> The subject states "remove". Removing received: header in full *WILL*
>> lead to creation of possibility of *nasty* email loops going undetected.
>
> Provided the said headers are removed at the very edge of the network,
> not before the message leaves the corporate network, I see no
> possibility of loop creation. What is a possible loop scenario in this
> setup?

Have you ever seen two hops loops?
[ e.g. smart host sends back to sending host ]

>> Rewriting "internal" received: headers (removing "private" parts) avoids
>> *this* risk.
>
> But this is equally wrong from the point of view of the RFC which
> states: "it MUST NOT alter in any way a Received: line that is already
> in the header".

IMHO full removal does alter the header :-)

I can see no reason to break the above "MUST NOT" on nets/servers under
my control. I can see reasons why some people want to break in very
specific case when the header has been generated by "internal server"
also under their control.


--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
"I shall expect a chemical cure for psychopathic behavior by 10 A.M. tomorrow,
or I'll have your guts for spaghetti."
-- a comic panel by Cotham

Grant Taylor wrote:

> *sigh*

> If you can not (or chose not) to understand why someone might not want
> to expose (some of) their internal network structure via extra Received:
> headers, I can not explain it to you.

I can understand perfectly why someone might *want* to hide that information.
I can also understand perfectly that it's *stupid* to think that hiding
the information actually makes you more secure.

> Ok, I'll bite and ask. How is Exchange and GroupWise not RFC compliant
> when they are running internal protocols (X.400 for Exchange) that (to
> the best of my knowledge) do not have the equivalent of Received:
> headers.

Sorry; I misread your post.

> There are ways to detect mail loops other than with Received: headers.

Received: headers are the *standard* way. Some of us think standards
actually matter.

> Will you please list one or two other reasons (other than "breaking RFC'
> and "mail loop detection") why removing / not adding internal Received:
> headers is bad?

If you don't think breaking RFC: and mail-loop detection/prevention
are good enough reasons... then fine; we are at an impasse.

>> By the way, e-mails I send go from shishi.roaringpenguin.com
>> (192.168.2.3) to vanadium.roaringpenguin.com (192.168.10.23) to
>> www.roaringpenguin.com (206.191.13.82) to the Internet. Now that you
>> know my internal network structure... am I more vulnerable than
>> before?

> Are you more vulnerable? That is tough to say. Presuming that you were
> truthful, I do have more information about your internal structure and
> information that I would very likely use in an attack (if I did such
> things).

I call bullshit.

> Based on the headers from a message you sent me the other day, I'm
> deducing / predicting the following:
> - ShiShi is your workstation that you sent the emails from. I know
> this based on what you have said which agrees with the headers in your
> message. You did not do any thing to hide or mis-represent your
> Received: headers did you???

That's right.

> - Vanadium is an edge SMTP server that has directly routable access to
> the 192.168.2.x network.

Ehm... not exactly.

> - Vanadium is connected to a generic internet connection on the
> 64.26.171.x network with a extremely generic looking reverse DNS.

Yep.

> - Vanadium is (or did) use www as a smart host, which would make sense
> considering the generic looking reverse DNS.

Yep.

> In short, if you (and everyone else in between) are not firewalling for
> spoofed packets, chances are good that I could send packets to Vanadium
> spoofing ShiShi as the source IP and the replies would end up being
> passed in to ShiShi.

Go ahead and try. shishi and vanadium both have private IP addresses,
so if you pull that trick off, I will be most impressed.

> Can I use this to directly exploit any thing? I'm
> not talented enough to say one way or the other. However the point
> being that I do already have some information on your internal network
> structure. I also have some network ranges to start throwing scans at
> to see what will and will not get through.

On a 192.168 address? Good luck. On the 64.26.171 address? That's
a public IP address anyway that you could find pretty quickly with
other means.

> Oh, ya, WWW is not adding any indication of authentication from
> Vanadium. So if I were an energetic spacker, I would be tempted to
> analyze the SMTP transaction with WWW so that I could predict the
> expected packets. If I can successfully predict the expected packets, I
> can possibly send them with the spoofed IP of Vanadium and rely traffic
> through your server.

Mmm... yeah... go ahead and try. :-) Good luck...

> Just think about how much harder it would be for me to exploit your
> systems if I did not have any thing other than the Received: header
> added by my server indicating that it received the message from www.

Once again, I call BS. The exploits you mentioned are completely
infeasible.

Regards,

David.

On 04/01/08 09:59, David F. Skoll wrote:
> I can understand perfectly why someone might *want* to hide that
> information. I can also understand perfectly that it's *stupid* to
> think that hiding the information actually makes you more secure.

I believe (my opinion) that each and every little thing that you do to
not expose information on top of all other security measures makes you a
little bit more secure by making you a harder target to hit. We are
both human and allowed to have different opinions. For now I think we
can both agree to disagree and move forward.

> Sorry; I misread your post.

I figured as much which is why I restated. There may be some stinky
opinions flying back and forth, but seeing as how there are no insults,
we can still discuss / debate / banter back and forth until one or the
other of us gets tired of this thread.

> Received: headers are the *standard* way. Some of us think standards
> actually matter.

I'll agree that Received: headers are the standard way to do it on the
open internet where SMTP is the standard protocol. However inside of
closed environments, where SMTP is optional, so is said method of
detecting loops.

> If you don't think breaking RFC: and mail-loop detection/prevention
> are good enough reasons... then fine; we are at an impasse.

I do not believe that removing Received: headers from outbound messages
at the SMTP edge of a network breaks mail-loop detection/prevention like
you are saying. However I am interested in having a discussion where
one or the other or both of us proposes our scenarios where things will
work and have the other poke holes in it if you are as well.

> I call bullshit.

If you have not altered or provided mis-information in your headers,
then I do indeed have some information about your set up. How useful
that information is can not be determined by its self. But I do still
have some purported information.

> That's right.

*nod*

> Ehm... not exactly.

Vanadium may not be an edge SMTP like I said, but I'm still sticking to
the fact that it appears that it has directly routable access to the
192.168.2.x network.

> Yep.

*nod*

> Yep.

*nod*

> Go ahead and try. shishi and vanadium both have private IP
> addresses, so if you pull that trick off, I will be most impressed.

Adding that tidbit of information I'm guessing that there is a NATing
firewall between Vanadium and the internet that I would have to get
through if I was to attack from the internet its self. However I do
have more information. Again the viability of the information is still
questionable.

> On a 192.168 address? Good luck. On the 64.26.171 address? That's
> a public IP address anyway that you could find pretty quickly with
> other means.

I can not directly attack your private range IP addresses. However I
could see how good your NATing firewall is. I wonder how much of a
reflected attack would get in. (Again, I'm just thinking out loud as I
will *NOT* do any of these things.)

> Mmm... yeah... go ahead and try. :-) Good luck...

I will do some more thinking about this and contact you off list if I am
more interested and you are willing to participate in a test (can I send
my someone a "Hello World" message or not).

> Once again, I call BS. The exploits you mentioned are completely
> infeasible.

Depending on what other forms of security you have in place, the things
I've mentioned may indeed be completely infeasible. How good is your
defense against social engineering? What about others in your house?
What would I gain if something was run from with in your network knowing
what you have exposed via your Received: headers and this news group?

To me, these are all crumbs along a long trail that can be used to
exploit someone. My simple opinion is that not leaving (exposing) these
crumbs (Received: headers) does indeed provide some (limited) additional
security by making you much harder to find and attempt to exploit.

> Regards

Thank you for taking the time to respond politely with decent though out
facts / opinions in a non insulting manner (unlike some other posters in
this group as of late).



Grant. . . .

Grant Taylor <gtaylor@riverviewtech.net> wrote:

> On 04/01/08 09:59, David F. Skoll wrote:
>> [...]
>> If you don't think breaking RFC: and mail-loop detection/prevention
>> are good enough reasons... then fine; we are at an impasse.
>
> I do not believe that removing Received: headers from outbound
> messages at the SMTP edge of a network breaks mail-loop
> detection/prevention like you are saying. However I am interested in
> having a discussion where one or the other or both of us proposes our
> scenarios where things will work and have the other poke holes in it
> if you are as well.

I have seen "two hops" mail loops with smart host sending back to
sending host. It makes me suggest replacing "removing in full" with
"removing protected data from headers".

> [...]

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick

On Tue, 01 Apr 2008 13:11:27 -0500, Grant Taylor wrote:

> I do not believe that removing Received: headers from outbound messages
> at the SMTP edge of a network breaks mail-loop detection/prevention like
> you are saying. However I am interested in having a discussion where
> one or the other or both of us proposes our scenarios where things will
> work and have the other poke holes in it if you are as well.

Please continue your discussion in comp.mail.misc. This newsgroup is
about sendmail, and your discussion isn't.

Greg Russell <me@privacy.net> wrote:

> On Tue, 01 Apr 2008 13:11:27 -0500, Grant Taylor wrote:
>
>> I do not believe that removing Received: headers from outbound messages
>> at the SMTP edge of a network breaks mail-loop detection/prevention like
>> you are saying. However I am interested in having a discussion where
>> one or the other or both of us proposes our scenarios where things will
>> work and have the other poke holes in it if you are as well.
>
> Please continue your discussion in comp.mail.misc. This newsgroup is
> about sendmail, and your discussion isn't.

0) The comp.mail.sendmail *is not* "overloaded"
1) The discussion started with statements like "other MTA can do it,
sendmail requires external programs (milters) to do it".

I think the discussion stays reasonably on topic in news:comp.mail.sendmail

--
[pl>en: Andrew] Andrzej Adam Filip anfi@xl.wp.pl sip:896530@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
When a lion meets another with a louder roar,
the first lion thinks the last a bore.
-- G. B. Shaw

On 04/01/08 13:14, Andrzej Adam Filip wrote:
> I have seen "two hops" mail loops with smart host sending back to
> sending host. It makes me suggest replacing "removing in full" with
> "removing protected data from headers".

Ok, I think I can go along with that.

If I may, let me suggest an example for discussion.

Received: from edgesmtp.receiver.com ...
by mailstore.receiver.com ...
Received: from smtp.company.com ...
by edgesmtp.receiver.com ...
Received: from smtp.department.company.com ...
by smtp.company.com ...
Received: from smtp.workgroup.department.company.com ...
by smtp.department.company.com ...
Received: from workstation.workgroup.department.company.com ...
by smtp.workgroup.department.company.com ...

Please show me (us) what you are recommending be done with the above
Received: headers.

....

What I'm proposing is that smtp.company.com remove (and log) the first
(bottom) three Received: headers from outbound messages. This way,
recipients out side of company.com will see the following Received: headers.

Received: from edgesmtp.receiver.com ...
by mailstore.receiver.com ...
Received: from smtp.company.com ...
by edgesmtp.receiver.com ...

Note that only messages leaving company.com would have their extra
Received: headers removed. Messages staying with in the company would
still have all the Received: headers in tact. I.e.

Received: from smtp.workgroup.differentdepartment.company.com ...
by test.workgroup.differentdepartment.company.com ...
Received: from smtp.differentdepartment.company.com ...
by smtp.workgroup.differentdepartment.company.com ...
Received: from smtp.department.company.com ...
by smtp.differentdepartment.company.com ...
Received: from smtp.workgroup.department.company.com ...
by smtp.department.company.com ...
Received: from workstation.workgroup.department.company.com ...
by smtp.workgroup.department.company.com ...



Grant. . . .