Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set clientDomain in SmtpClient #27765

Closed
olmobrutall opened this issue Oct 30, 2018 · 2 comments
Closed

Set clientDomain in SmtpClient #27765

olmobrutall opened this issue Oct 30, 2018 · 2 comments
Labels
area-System.Net enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors
Milestone

Comments

@olmobrutall
Copy link

olmobrutall commented Oct 30, 2018

(moved from dotnet/core#2031)

The old implementation of SmtpClient (https://referencesource.microsoft.com/#system/net/System/Net/mail/SmtpClient.cs) was able to use the clientDomain from configuration MailConfiguration.Smtp.Network.ClientDomain;

  <smtp>
     <network host="somehost" port="25" clientDomain="mymachine.mydomain.com" enableSsl="false" />
  </smtp>

solving problems like this one: https://stackoverflow.com/questions/37410598/fqdn-with-smtpclient-in-powershell

But in the .Net Core implementation https://github.com/dotnet/corefx/blob/master/src/System.Net.Mail/src/System/Net/Mail/SmtpClient.cs only the fallback to IPGlobalProperties.GetIPGlobalProperties().HostName; is implemented.

Unfortunately, I get a SmtpException because my Smtp server requires fully-qualified hostnames:

image

Maybe we can find a solution by changing the SMTP server, but our admins say that FQDN check is a POSTFIX default setting, so I'm surprised I'm the only one having this problem.

Thanks

@karelz
Copy link
Member

karelz commented Oct 30, 2018

You are apparently the first one to need it (or at least to say so here on our repo). I haven't seen any other issue filed to request that.
We consider SmtpClient legacy API and we do not plan significant investments in it. Our recommendation is to use MailKit or other community solutions instead - see platform-compat rule and Networking roadmap.

That said. If it is important to you and if the implementation is straightforward, we would be likely ok to take a PR.

@karelz
Copy link
Member

karelz commented Oct 1, 2019

Triage: It may require new API actually.

Only 1 upvote in 1 year, no takers to implement it -- closing.

@karelz karelz closed this as completed Oct 1, 2019
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
bartonjs pushed a commit to bartonjs/runtime that referenced this issue Feb 1, 2020
Fix unhandled exception line number issues

There are a few paths to get the place (DebugStackTrace::DebugStackTraceElement::InitPass2) where
the offset/ip needs an adjustment:

1) The System.Diagnostics.StackTrace constructors that take an exception object. The stack trace in
   the exception object is used (from the _stackTrace field).
2) Processing an unhandled exception for display (ExceptionTracker::ProcessOSExceptionNotification).
3) The System.Diagnostics.StackTrace constructors that don't take an exception object that get the
   stack trace of the current thread.

For cases #1 and #2 the StackTraceInfo/StackTraceElement structs are built when the stack trace
for an exception is generated and is put in the private _stackTrace Exception object field. The
IP in each StackTraceElement is decremented for hardware exceptions and not for software exceptions
because the CrawlFrame isInterrupted/hasFaulted fields are not initialized (always false). This is
backwards for h/w exceptions leaf node frames but really can't be changed to be compatible with
other code in the runtime and SOS.

The fIsLastFrameFromForeignStackTrace BOOL in the StackTraceElement/DebugStackTraceElement structs
have been replaced with INT "flags" field defined by the StackTraceElementFlags enum. There is a new
flag that is set (STEF_IP_ADJUSTED) if the IP has been already adjusted/decremented. This flag is
used to adjust the native offset when it is converted to an IL offset for source/line number lookup
in DebugStackTraceElement::InitPass2().

When the stack trace for an exception is rendered to a string (via the GetStackFramesInternal FCALL)
the internal GetStackFramesData/DebugStackTraceElement structs are initialized. This new "flags"
field is passed from the StackTraceElement to the DebugStackTraceElement struct.

For case #3 all this happens in the GetStackFramesInternal FCALL called from the managed constructor
building the GetStackFramesData/DebugStackTraceElement structs directly.

Fixes issues dotnet#27765 and dotnet#25740.

Fix IL offset map search.
@ghost ghost locked as resolved and limited conversation to collaborators Dec 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors
Projects
None yet
Development

No branches or pull requests

3 participants