Re: Remove Internal Hops from Header

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

Relevant Pages

  • Re: can someone decipher this?
    ... First, the 'Received:' headers are always ordered most-recent-first, so ... 'Message-id' is an internal id assigned to ... the message by the smtp server - administrators can use this to trace it ... 'X-Originalarrivaltime:' is not part of the standard set of headers, ...
    (Security-Basics)
  • two strange issues...
    ... Default setup rules for the Edge Firewall ... rules to publish web servers on the internal network. ... I see that it's attempted a few SMTP connections to my SMTP publish. ... SMTP server I use is a spam filter SMTP relay called ASSP. ...
    (microsoft.public.isa)
  • Re: IIS SMTP server in a redundant formation?
    ... can use very low TTLs to ensure reordering of the RRset, but the SMTP RFC dictates that the client randomizes as well. ... In my experience once a client (in this case a sending SMTP server) resolves and successfully connects to a destination SMTP server they rarely will connect to a different destination SMTP server unless their cached query is pushed out. ...
    (microsoft.public.inetserver.iis.smtp_nntp)
  • Re: Redirect loses some header information
    ... 2002 at home and Outlook 2003 at work and there is no redirect rule. ... has it already been converted to the proprietary format used by Outlook? ... Presumably it would also use the DATA command to send the mail to the SMTP server so it wouldn't care about what is in the headers to deliver the mail because it would use the RCPT-TO command to the SMTP server. ...
    (microsoft.public.outlook)
  • Re: How find which email a spammer used?
    ... The e-mail client sends a RCPT-TO command to the SMTP server to tell it where to deliver an e-mail, and that doesn't have to be a destination noted in a header. ... The headers are just part of the e-mail message. ... Each mail server will prepend a Received header, so you trace backwards from the topmost Received header since that is the newest one (the topmost one will be the one added my your mail server when it received the message, and it may or may not specified the target e-mail account). ...
    (microsoft.public.outlook)