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

Return the reply from SMTP server when sending single message #92

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ljosa
Copy link
Collaborator

@ljosa ljosa commented Jan 3, 2018

Return the reply because it may contain useful information for logging
and tracking. In particular, Amazon SES insists on assigning a new
Message ID rather than trusting the one we send them, and they return
the assigned Message ID in the reply, after "250 Ok".

Only do this when smtp-send is called with a single message. (This
is the common use case, which is documented and supported by
postal.core.)

If someone manages to call smtp-send with multiple messages, then
return a response without the server replies, as before. (The
alternative, which is to complicate the response from smtp-send to
incorporate multiple replies while remaining backwards compatible,
does not seem worth it---especially because sending multiple messages
at a time is not something you should do if you care to know which
ones succeeded.)

Return the reply because it may contain useful information for logging
and tracking. In particular, Amazon SES insists on assigning a new
Message ID rather than trusting the one we send them, and they return
the assigned Message ID in the reply, after "250 Ok".

Only do this when `smtp-send` is called with a single message. (This
is the common use case, which is documented and supported by
postal.core.)

If someone manages to call `smtp-send` with multiple messages, then
return a response without the server replies, as before. (The
alternative, which is to complicate the response from `smtp-send` to
incorporate multiple replies while remaining backwards compatible,
does not seem worth it---especially because sending multiple messages
at a time is not something you should do if you care to know which
ones succeeded.)

(defn- send-multiple [transport jmsgs]
(doseq [^javax.mail.Message jmsg jmsgs]
(.sendMessage transport jmsg (.getAllRecipients jmsg)))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not reuse send-single here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, that's be fine. I'll change that.

@drewr
Copy link
Owner

drewr commented Jan 4, 2018

This is great, thanks @ljosa! Left a question but otherwise looks good.

Phil Hagelberg
Roman Flammer
Sam Ritchie
Stephen Nelson

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note you removed all the newlines from these (or, likely your editor did).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Yes, I have configured emacs to remove trailng spaces. Sorry for not reviewing the commit more thoroughly.

(defn- send-multiple [transport jmsgs]
(doseq [^javax.mail.Message jmsg jmsgs]
(send-single transport jmsg))
{:code 0 :error :SUCCESS :message "messages sent"})
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this single return value will mask all the return values from the send-single invocations, which could have an error. Likely want to return a vec here that the user can scan through.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe sendMessage will throw an exception if any of the messages fail. For that reason, the API for sending multiple messages is problematic. (If something fails, it's hard for the caller to figure out which messages succeeded.) But it's fine for callers that don't care to track that anyway.

I tried to not change the interface at all, since you might have users that depend on it. I'm not sure what policy you have for breaking changes.

@drewr drewr force-pushed the master branch 4 times, most recently from b199c5a to 382cb0e Compare November 18, 2020 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants