Ability to return custom responses?

[oogali]

I'd like to return custom responses in response to the execution of the Mail, Rcpt, and Data functions of the Session object.

I see I can string together my own responses using SMTPError, however the logic in the connection handling code doesn't particularly like receiving any sort of error.

Would it be against the spirit of the project if this logic was modified to further inspect SMTPError and only error out if SMTPError.Code was not 250?

[oogali]

As an example...

	return &smtp.SMTPError{
		Code:         250,
		EnhancedCode: smtp.EnhancedCode{2, 0, 0},
		Message:      fmt.Sprintf("Ok: queued as %s", queueID),
	}

[emersion]

We already allow this for a bunch of functions, see e.g.

go-smtp/conn.go

Line 451 in 689d1d4

if smtpErr, ok := err.(*SMTPError); ok {

Maybe we're missing some others

[foxcpp]

We already allow this for a bunch of functions, see e.g.

It is not going to work correctly since s.recipients list is not being populated.

[foxcpp]

Speaking of "spirit of the project". I believe having any useful text in success responses has marginal benefit since most (all?) client implementations will just discard it. What is the use case?

[foxcpp]

If you have fingerprinting concerns or just do not like silly responses, we can replace it with just "Ok". :)

[emersion]

Ah, right, this is about the success reply. Not sure it's worth it to do anything complicated to support this.

[oogali]

@foxcpp The use case is more for traceability -- to be able to trace the message from the ingestion point (go-smtp) to the final delivery/handoff.

This is more for troubleshooting and monitoring rather than for consumption by any random SMTP client.

[oogali]

I'm more interested in this on DATA than any other command (to surface the internal queue ID).

[gowthamgts]

@oogali - same use-case for me as well. @emersion - no plans to add this?

[kayrus]

@oogali @gowthamgts Mail and Rcpt should be solved in #188