当我通过其中一个大型提供商发送电子邮件时：Google，yahoo，hotmail。 System.Net.Mail在标题ex：Received：来自Andriy-PC（XXXX.comcastbusiness.net。[XXX.XXX.XXX.XXX]）中公开我的IP地址和电脑名称
有没有办法将其从电子邮件中删除？
这是我的代码：
Dim SmtpServer As New SmtpClient()
Dim mail As New MailMessage()
SmtpServer.Credentials = New _
Net.NetworkCredential(email.account, email.pass)
SmtpServer.Port = email.port
SmtpServer.Host = email.smtp
If email.ssl = 1 Then
SmtpServer.EnableSsl = True
Else
SmtpServer.EnableSsl = False
End If
mail = New MailMessage()
mail.From = New MailAddress(email.account)
mail.To.Add(recipient)
mail.Subject = user_subject
mail.Body = body
mail.Sender = New MailAddress(email.account)
SmtpServer.Send(mail)
答案 0 :(得分：0)
简短回答是否。根据SMTP规范无法删除它，这些规范要求正确符合的MTA（邮件传输代理）在邮件中继时添加received标头，建立received标题的“监管链”列表，允许用户追踪邮件从发件人到收件人的行进方式。
有关详细信息，请参阅RFC 5321和RFC 5322，特别是RFC 5321的§4.4：
4.4. Trace Information
When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content, as discussed in
Section 4.1.1.4.
This line MUST be structured as follows:
o The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.
o The ID clause MAY contain an "@" as suggested in RFC 822, but this
is not required.
o If the FOR clause appears, it MUST contain exactly one <path>
entry, even when multiple RCPT commands have been given. Multiple
<path>s raise some security issues and have been deprecated, see
Section 7.2.
An Internet mail program MUST NOT change or delete a Received: line
that was previously added to the message header section. SMTP
servers MUST prepend Received lines to messages; they MUST NOT change
the order of existing lines or insert Received lines in any other
location.
As the Internet grows, comparability of Received header fields is
important for detecting problems, especially slow relays. SMTP
servers that create Received header fields SHOULD use explicit
offsets in the dates (e.g., -0800), rather than time zone names of
any type. Local time (with an offset) SHOULD be used rather than UT
when feasible. This formulation allows slightly more information
about local circumstances to be specified. If UT is needed, the
receiver need merely do some simple arithmetic to convert the values.
Use of UT loses information about the time zone-location of the
server. If it is desired to supply a time zone name, it SHOULD be
included in a comment.
When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the <reverse-
path> from the MAIL command. Here, final delivery means the message
has left the SMTP environment. Normally, this would mean it had been
delivered to the destination user or an associated mail drop, but in
some cases it may be further processed and transmitted by another
mail system.
It is possible for the mailbox in the return path to be different
from the actual sender's mailbox, for example, if error responses are
to be delivered to a special error handling mailbox rather than to
the message sender. When mailing lists are involved, this
arrangement is common and useful as a means of directing errors to
the list maintainer rather than the message originator.
The text above implies that the final mail data will begin with a
return path line, followed by one or more time stamp lines. These
lines will be followed by the rest of the mail data: first the
balance of the mail header section and then the body (RFC 5322 [4]).
It is sometimes difficult for an SMTP server to determine whether or
not it is making final delivery since forwarding or other operations
may occur after the message is accepted for delivery. Consequently,
any further (forwarding, gateway, or relay) systems MAY remove the
return path and rebuild the MAIL command as needed to ensure that
exactly one such line appears in a delivered message.
A message-originating SMTP system SHOULD NOT send a message that
already contains a Return-path header field. SMTP servers performing
a relay function MUST NOT inspect the message data, and especially
not to the extent needed to determine if Return-path header fields
are present. SMTP servers making final delivery MAY remove Return-
path header fields before adding their own.
The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent. For this to be unambiguous, exactly one return path
SHOULD be present when the message is delivered. Systems using RFC
822 syntax with non-SMTP transports SHOULD designate an unambiguous
address, associated with the transport envelope, to which error
reports (e.g., non-delivery messages) should be sent.
Historical note: Text in RFC 822 that appears to contradict the use
of the Return-path header field (or the envelope reverse-path address
from the MAIL command) as the destination for error messages is not
applicable on the Internet. The reverse-path address (as copied into
the Return-path) MUST be used as the target of any mail containing
delivery error messages.
In particular:
o a gateway from SMTP -> elsewhere SHOULD insert a return-path
header field, unless it is known that the "elsewhere" transport
also uses Internet domain addresses and maintains the envelope
sender address separately.
o a gateway from elsewhere -> SMTP SHOULD delete any return-path
header field present in the message, and either copy that
information to the SMTP envelope or combine it with information
present in the envelope of the other transport system to construct
the reverse-path argument to the MAIL command in the SMTP
envelope.
The server must give special treatment to cases in which the
processing following the end of mail data indication is only
partially successful. This could happen if, after accepting several
recipients and the mail data, the SMTP server finds that the mail
data could be successfully delivered to some, but not all, of the
recipients. In such cases, the response to the DATA command MUST be
an OK reply. However, the SMTP server MUST compose and send an
"undeliverable mail" notification message to the originator of the
message.
A single notification listing all of the failed recipients or
separate notification messages MUST be sent for each failed
recipient. For economy of processing by the sender, the former
SHOULD be used when possible. Note that the key difference between
handling aliases (Section 3.9.1) and forwarding (this subsection) is
the change to the backward-pointing address in this case. All
notification messages about undeliverable mail MUST be sent using the
MAIL command (even if they result from processing the obsolete SEND,
SOML, or SAML commands) and MUST use a null return path as discussed
in Section 3.6.
The time stamp line and the return path line are formally defined as
follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
[4]):
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time
; where "date-time" is as defined in RFC 5322 [4]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
From-domain = "FROM" FWS Extended-Domain
By-domain = CFWS "BY" FWS Extended-Domain
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( address-literal FWS "(" TCP-info ")" )
TCP-info = address-literal / ( Domain FWS address-literal )
; Information derived by server from TCP connection
; not client EHLO.
Opt-info = [Via] [With] [ID] [For]
[Additional-Registered-Clauses]
Via = CFWS "VIA" FWS Link
With = CFWS "WITH" FWS Protocol
ID = CFWS "ID" FWS ( Atom / msg-id )
; msg-id is defined in RFC 5322 [4]
For = CFWS "FOR" FWS ( Path / Mailbox )
Additional-Registered-Clauses = CFWS Atom FWS String
; Additional standard clauses may be
added in this
; location by future standards and
registration with
; IANA. SMTP servers SHOULD NOT use
unregistered
; names. See Section 8.
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are
; registered with the Internet Assigned Numbers
; Authority (IANA). "Via" is primarily of value
; with non-Internet transports. SMTP servers
; SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are
; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters"
; registry [9]. SMTP servers SHOULD NOT
; use unregistered names.