-
Notifications
You must be signed in to change notification settings - Fork 229
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
Server & Client: Implementing DSN extension (RFC 3461, RFC 6533) #233
Conversation
bdf6b38
to
45d55a3
Compare
Some notes:
|
76f990b
to
fd8acd9
Compare
I've done what I could. |
smtp.go
Outdated
type DSNNotify string | ||
|
||
const ( | ||
NotifyNever DSNNotify = "NEVER" | ||
NotifyDelayed DSNNotify = "DELAY" | ||
NotifyFailure DSNNotify = "FAILURE" | ||
NotifySuccess DSNNotify = "SUCCESS" | ||
) | ||
|
||
type DSNAddressType string | ||
|
||
const ( | ||
AddressTypeRFC822 DSNAddressType = "RFC822" | ||
AddressTypeUTF8 DSNAddressType = "UTF-8" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a bit inconsistent to have the types prefixed with "DSN" but not the constants. Is this deliberate? Should we prefix everything with "DSN", or do you think we can drop the "DSN" prefix from type names?
(Sorry for the delay!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've went with the prefix everywhere.
// present. It also matches disallowed characters in QCHAR and QUCHAR defined | ||
// in above. | ||
// So it allows us to detect malformed values and report them appropriately. | ||
var eUOrDCharRe = regexp.MustCompile(`\\x[{][0-9A-F]+[}]|[[:cntrl:] \\+=]`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I'm not a fan of using regexp for decoding but we already do that in go-smtp so it's not a big deal…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan too, but could't think of a better way.
client.go
Outdated
cmdStr := "MAIL FROM:<%s>" | ||
|
||
var sb strings.Builder | ||
sb.Grow(510 + 14 + 26 + 11 + 9 + 9 + 39 + 500) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, this seems a bit like micro-optimization with these magic constants... I'd prefer to leave this out or just pick a reasonably high enough power of 2 value.
These are mostly just nits, I think this is overall good to go. |
6006fd4
to
341be50
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
Closes #32.