-
Notifications
You must be signed in to change notification settings - Fork 580
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
Delivery #4
Comments
Really liking mailcatcher so far. Not sure if this is the same issue, but I'm getting "503 MAIL already given" when trying to send to multiple unique recipients on the same connection. Would gladly help to sponsor this feature with a donation. Thanks! |
Thanks for your interest! It sounds like whatever you're using to send mail is doing some funky things with the protocol. You should only be sending a single "MAIL" command which includes the from address, then you can send as many "RCPT TO" commands as you like to add multiple unique senders. MailCatcher should handle that fine. Maybe check out the SMTP RFC for details. |
Thanks so much for the reply. I am using SwiftMailer (swiftmailer.org) for sending. When I change the smtp connection to use SendGrid (sendgrid.com) or another smtp server that I use, everything works out fine. So I "think" everything should be fine with the protocol but I admit I can't see the exact commands being sent to the mail servers. I'll see if I can turn on some logging to see the exact commands and pass them along. |
So SwiftMailer was indeed sending multiple MAIL FROM commands, which seemed to work fine with other smtp servers. The "protocols/smtpserver.rb" file of the EventMachine gem definitely does not allow this though. (http://eventmachine.rubyforge.org/svn/trunk/lib/protocols/smtpserver.rb) I commented out the 2 lines from the "process_mail_from" function that were checking for this, restarted Mailcatcher and everything worked great. I'm definitely not a ruby programmer but as far as I can tell I didn't break anything else. |
Glad you've found a solution. I don't want to build a workaround into MailCatcher for broken clients, perhaps you can patch SwiftMailer? In the meantime you know how to get it working. :-) |
I just ran into this issue myself. See a very simple example using net/smtp in this gist: https://gist.github.com/2236751 Where in the RFC does it state you can't send multiple MAIL commands? I see this in section 3.3
|
FWIW, @crucialwebstudio's "fix" to comment out the lines in EM worked for me too. Pretty sure this isn't an issue of a broken client but rather a broken implementation in EM. I'll take it up with them. |
@pjb3 you can certainly send multiple MAIL commands, but it should reset the state of the SMTP exchange. The SwiftMailer client was sending multiple MAIL commands for a single message. Your issue is slightly different—you should indeed be able to send multiple messages sequentially over the same connection. MailCatcher is set up to do so, the problem is in eventmachine. A repeat MAIL command should reset the state instead of the current error-out behaviour. They haven't fixed it in master either. Send a pull request! Should be simple to slice the state array and send a receive_reset, which should have the same semantic value. |
There is a pull request that fixes this issue: eventmachine/eventmachine#288 YMMV but commenting out the relevant lines in process_mail_from didn't work for me, but the pull request above worked fine for me. |
We wanted to use mailcatcher to QA all outgoing mail, but still not block regular mail delivery. Here's what we did: First, create this wrapper script in #!/usr/bin/ruby
# This script multiplexes both STDIN and ARGV to two mail programs:
# sendmail, and catchmail (for QA).
handlers = [
'/usr/sbin/sendmail -t -i',
'/usr/local/bin/catchmail',
]
contents = $stdin.read
handlers.each do |cmd|
IO.popen(cmd.split + ARGV, 'w') do |f|
f.write(contents)
end
end Then we use it just like we use the
Very handy! |
It would be nice if MailCatcher could on-send captured messages to their intended recipients, or a separately provided recipient.
The text was updated successfully, but these errors were encountered: