Remove Internal Hops from Header
wel...@gmail.com
of outbound email when a sendmail MTA is the last hop before talking
to hosts on the internet?
J
Rob MacGregor
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.'"
Victor Sudakov
> > 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/
Rob MacGregor
>
> 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.
Victor Sudakov
> >
> > 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 helper, 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.
David F. Skoll
> 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 helper, 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.
Victor Sudakov
> > 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 helper, 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.
Grant Taylor
> 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. . . .
David F. Skoll
> 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.
David F. Skoll
> 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.
Grant Taylor
> 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 help 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. . . .
Victor Sudakov
> > 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.
Andrzej Adam Filip
> 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 an...@xl.wp.pl sip:896...@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"
Andrzej Adam Filip
*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 an...@xl.wp.pl sip:896...@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
The knowledge that makes us cherish innocence makes innocence unattainable.
-- Irving Howe
Victor Sudakov
> >> > 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".
Andrzej Adam Filip
> 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 an...@xl.wp.pl sip:896...@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
David F. Skoll
> *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.
Grant Taylor
> 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 help
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. . . .
Andrzej Adam Filip
> 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 an...@xl.wp.pl sip:896...@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
Greg Russell
> 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.
Andrzej Adam Filip
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 an...@xl.wp.pl sip:896...@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
Grant Taylor
> 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. . . .
Andrzej Adam Filip
> 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.
As I understand the minimum Received: header must contain:
Received: "from" host "by" host ; date
0) I suggest leaving date as it is (may be stripping seconds part)
1) removing any IP address info
2) replacing "real names" with "function names" or
"salted" CRC/md5/... codes
I think it should satisfy "non military grade" requirements :-)
> ...
>
> 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 ...
An alternative "loop prevention" methodology may place/detect special
"magic marks" in preserved/generated "received:" headers and treat such
marks in incoming mail as loop indicators.
--
[pl>en: Andrew] Andrzej Adam Filip an...@xl.wp.pl sip:896...@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Hark ye, Clinker, you are a most notorious offender. You stand convicted of
sickness, hunger, wretchedness, and want.
-- Tobias Smollet
Grant Taylor
> As I understand the minimum Received: header must contain:
> Received: "from" host "by" host ; date
>
> 0) I suggest leaving date as it is (may be stripping seconds part)
> 1) removing any IP address info
> 2) replacing "real names" with "function names" or
> "salted" CRC/md5/... codes
>
> I think it should satisfy "non military grade" requirements :-)
Agreed.
Sorry, let me clarify, I was not wanting to alter the field with in the
Received: header, I was just using "..." because I did not want to type
all the other information in the examples. All I'm wanting to do is
remove specific Received: headers, not modify the contents of any of the
headers.
> An alternative "loop prevention" methodology may place/detect special
> "magic marks" in preserved/generated "received:" headers and treat such
> marks in incoming mail as loop indicators.
Agreed.
Grant. . . .
Andrzej Adam Filip
*My* stance is that
1) modifying/removing "*internal*" received: header should be avoided
even at high cost but not at any cost
2) *IF* anybody wants to do it against good advises *AND* RFC "MUST NOT"
recommendations *THEN* I am ready to give advises how to avoid some
easy to predict potential problems
--
[pl>en: Andrew] Andrzej Adam Filip an...@xl.wp.pl sip:896...@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Writing about music is like dancing about architecture.
-- Frank Zappa
Victor Sudakov
> >> >> > 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?
I have not seen mail loops for a long time already. The last ones I
saw were with some complicated UUCP+SMTP setups.
> [ e.g. smart host sends back to sending host ]
What do you mean by "smart host" in this context? The corporate
mailhub which is supposed to perform headers removal before passing
mail into the Internet, or the ISP smarthost outside the corporate network?
> >> 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.
^^^^^^^^^^^^ Yes, I am talking exactly of this scenario.
Andrzej Adam Filip
ISP smart hosts are most frequently part of such short loops but
"stripping mail server" we discuss *MAY* be a part of such loops too.
BTW There are also "single user ~/.forward loops".
>> >> 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.
>
> ^^^^^^^^^^^^ Yes, I am talking exactly of this scenario.
I know and remember *otherwise* you would get proper bashing as
"RFC 'MUST NOT' breaker" :-)
--
[pl>en: Andrew] Andrzej Adam Filip an...@xl.wp.pl sip:896...@fwd.pulver.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Confessions may be good for the soul, but they are bad for the reputation.
-- Lord Thomas Dewar
Victor Sudakov
If the "stripping mail server" receives mail back from the ISP smart
host (in error), of course it should not strip the "Received" header
added by the ISP. So it will detect the loop.
> BTW There are also "single user ~/.forward loops".
You mean the mail would be forwarded out of the corporate network and
then back thereto? Otherwise such a loop would be detected before the
mail leaves the corporate network.
Andrzej Adam Filip
*Traditional* loop detection merely counts number of "received: like"
headers - it does not check content of the headers.
The wording of the suggestion have not excluded possibility of removing
*all* Received: headers from messages going "outside". It would cause
removing Received: headers "added by ISP" in messages forwarded by the
"internal forward" going "outside".
--
[pl>en: Andrew] Andrzej Adam Filip an...@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Plastic... Aluminum... These are the inheritors of the Universe!
Flesh and Blood have had their day... and that day is past!
-- Green Lantern Comics
privac...@googlemail.com
your self-righteous thou shalt nots...
It is perfectly legitimate to want to hide your internal structure.
Does this give you increased security? Well actually YES although as
all you SHOUTERS have been pointing out for the last 10 years it
should not be relied upon. It's just another layer.
Does this give you privacy? YES. A closed relay requiring
authentication from authorised users is accepting responsibility for
the message and it's perfectly reasonable that the sender should be
able to hide their own IP address from the hop.
FFS you really all should get a grip of yourselves and consider
etiquette and the fact that the people posting a question may have
thought about their needs rather than have everyone pick over old
ground again and again and again.
No wonder sendmail is being ditched faster than a Phorm-infested ISP.