Added LocalDomain for setting Mailkit parameter of same name.

[rkramer1964]

Added LocalDomain for setting Mailkit parameter of same name. Fixed failing test that needs to NOT send eagerly

[nblumhardt]

Thanks for sending this one. MailKit has rather a lot of configuration options, I'm wondering whether, instead of adding all of these, the Options type in this project might just need a ConfigureSmtpClient callback which can be used to interact with the MailKit SmtpClient?

[rkramer1964]

Maybe, my problem was that my server has postfix configured to require an FQDN on HELO and the windows workstation needing to send the log was not set up with an FQDN on its private network, so I kinda had to force it. Trying to get a full log transcript for each periodic run of my utility emailed and the batching sink is withholding some messages, even now. So I might be working on a sink based on textwriter which emails on dispose... Would you be interested in a sink like that?

On 2025-04-19 16:42, Nicholas Blumhardt wrote: Thanks for sending this one. MailKit has rather a lot of configuration options, I'm wondering whether, instead of adding all of these, the Options type in this project might just need a ConfigureSmtpClient callback which can be used to interact with the MailKit SmtpClient? -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: ***@***.***> nblumhardt left a comment (serilog/serilog-sinks-email#149) [1] Thanks for sending this one. MailKit has rather a lot of configuration options, I'm wondering whether, instead of adding all of these, the Options type in this project might just need a ConfigureSmtpClient callback which can be used to interact with the MailKit SmtpClient? -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: ***@***.***>

Links: ------ [1] #149 (comment) [2] https://github.com/notifications/unsubscribe-auth/AGNY7XRYH6XSZBCGJFKZJMD22K7MZAVCNFSM6AAAAAB3MDZXKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJWHA3TMOJVGE

[rkramer1964]

I was thinking more about this overnight. What if you had an Action<SmtpClient> parameter (kind of like authentication) that directly configured the MailKit client. This action could be called at each email sending occurrence so that things like Subject, etc. could be changed based on ambient conditions, e.g. Subject = "Backup Failure" or "Backup Success" so that someone monitoring the emails could have an "at a glance" view. Maybe instead of action, Func<SmtpClient, bool> where false aborts the transmit? Just my random 2am thoughts.

On 2025-04-19 16:42, Nicholas Blumhardt wrote: Thanks for sending this one. MailKit has rather a lot of configuration options, I'm wondering whether, instead of adding all of these, the Options type in this project might just need a ConfigureSmtpClient callback which can be used to interact with the MailKit SmtpClient? -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: ***@***.***> nblumhardt left a comment (serilog/serilog-sinks-email#149) [1] Thanks for sending this one. MailKit has rather a lot of configuration options, I'm wondering whether, instead of adding all of these, the Options type in this project might just need a ConfigureSmtpClient callback which can be used to interact with the MailKit SmtpClient? -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: ***@***.***>

Links: ------ [1] #149 (comment) [2] https://github.com/notifications/unsubscribe-auth/AGNY7XRYH6XSZBCGJFKZJMD22K7MZAVCNFSM6AAAAAB3MDZXKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJWHA3TMOJVGE

[nblumhardt]

Thanks for the suggestions! I think where possible, we should lean on Serilog's existing functionality for dynamic tasks like filtering or parameterisation.

For example, returning a bool from the callback would achieve what's already possible via WriteTo.Conditional(..), which has the advantages of working properly in conjunction with batching, and which saves some cycles by short-circuiting before events get to the underlying sink infrastructure.

Dynamically changing the subject could similarly be achieved using WriteTo.Map(..) (from Serilog.Sinks.Map), and this also works better with orthogonal features like batching.

[rkramer1964]

Understood.

On 2025-04-22 17:31, Nicholas Blumhardt wrote: Thanks for the suggestions! I think where possible, we should lean on Serilog's existing functionality for dynamic tasks like filtering or parameterisation. For example, returning a bool from the callback would achieve what's already possible via WriteTo.Conditional(..), which has the advantages of working properly in conjunction with batching, and which saves some cycles by short-circuiting before events get to the underlying sink infrastructure. Dynamically changing the subject could similarly be achieved using WriteTo.Map(..) (from _Serilog.Sinks.Map_), and this also works better with orthogonal features like batching. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: ***@***.***> nblumhardt left a comment (serilog/serilog-sinks-email#149) [1] Thanks for the suggestions! I think where possible, we should lean on Serilog's existing functionality for dynamic tasks like filtering or parameterisation. For example, returning a bool from the callback would achieve what's already possible via WriteTo.Conditional(..), which has the advantages of working properly in conjunction with batching, and which saves some cycles by short-circuiting before events get to the underlying sink infrastructure. Dynamically changing the subject could similarly be achieved using WriteTo.Map(..) (from _Serilog.Sinks.Map_), and this also works better with orthogonal features like batching. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: ***@***.***>

Links: ------ [1] #149 (comment) [2] https://github.com/notifications/unsubscribe-auth/AGNY7XV4MBKGQJAZARROLNT2227KXAVCNFSM6AAAAAB3MDZXKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRSGYYTOMBVHA