Re: Remove Internal Hops from Header

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

.

Relevant Pages

  • Re: email headers
    ... If an email has an internet header ... "Internet headers" isn't quite the correct term; those would be RFC required ... it actually connects to the Mercury/32 SMTP server. ...
    (microsoft.public.security.virus)
  • Re: New Years Resolution (was Re: cell phones, was: car help, was: Starving people refuse to eat foo
    ... my new year's resolution is to stop repeatedly defending ... It's not at all clear whether Internet RFCs are binding on Usenet. ... I won't complain about ... so long as they use the correct headers." ...
    (rec.arts.sf.written)
  • Re: Email Virus
    ... >> Each Received is a postmaster receiving the message with ... > Here are the headers from one such eamil I received. ... enter.net ISP is the true sender. ...
    (comp.os.linux.security)
  • Re: Do not PASS go, go to ChessCafe, do not collect royalties.
    ... our own Louis Blair - lately he has even denied receiving materials sent ... How many email systems exist without headers? ... even prevents you from saying what the lie is - I merely said I received ... two e-mails from you, which I did. ...
    (rec.games.chess.politics)
  • Re: Blind copies not being sent
    ... that the average home computer user doesn't have the skills needed to operate ... have put in firewall blocks to prevent those users from spewing all over the ... Internet and ruining their reputation. ... and you will see several "Received:" headers that trace how the ...
    (comp.mail.sendmail)