Class | EventMachine::Protocols::SmtpServer |
In: |
lib/protocols/smtpserver.rb
|
Parent: | EventMachine::Connection |
HeloRegex | = | /\AHELO\s*/i |
EhloRegex | = | /\AEHLO\s*/i |
QuitRegex | = | /\AQUIT/i |
MailFromRegex | = | /\AMAIL FROM:\s*/i |
RcptToRegex | = | /\ARCPT TO:\s*/i |
DataRegex | = | /\ADATA/i |
NoopRegex | = | /\ANOOP/i |
RsetRegex | = | /\ARSET/i |
VrfyRegex | = | /\AVRFY\s+/i |
ExpnRegex | = | /\AEXPN\s+/i |
HelpRegex | = | /\AHELP/i |
StarttlsRegex | = | /\ASTARTTLS/i |
AuthRegex | = | /\AAUTH\s+/i |
In SMTP, the server talks first. But by a (perhaps flawed) axiom in EM, post_init will execute BEFORE the block passed to start_server, for any given accepted connection. Since in this class we‘ll probably be getting a lot of initialization parameters, we want the guts of post_init to run AFTER the application has initialized the connection object. So we use a spawn to schedule the post_init to run later. It‘s a little weird, I admit. A reasonable alternative would be to set parameters as a class variable and to do that before accepting any connections.
OBSOLETE, now we have @@parms. But the spawn is nice to keep as an illustration.
Send the incoming data to the application one chunk at a time, rather than one line at a time. That lets the application be a little more flexible about storing to disk, etc. Since we clear the chunk array every time we submit it, the caller needs to be aware to do things like dup it if he wants to keep it around across calls.
DON‘T reset the transaction upon disposition of the incoming message. This means another DATA command can be accepted with the same sender and recipients. If the client wants to reset, he can call RSET. Not sure whether the standard requires a transaction-reset at this point, but it appears not to.
User-written code can return a Deferrable as a response from receive_message.
Sent when data from the remote peer is available. The size can be controlled by setting the :chunksize parameter. This call can be made multiple times. The goal is to strike a balance between sending the data to the application one line at a time, and holding all of a very large message in memory.
Called when the remote peer sends the DATA command. Returning false will cause us to send a 550 error to the peer. This can be useful for dealing with problems that arise from processing the whole set of sender and recipients.
A false response from this user-overridable method will cause a 550 error to be returned to the remote client.
Sent after a message has been completely received. User code must return true or false to indicate whether the message has been accepted for delivery.
Receives the argument of a RCPT TO command. Can be given multiple times per transaction. Return false to reject the recipient.
Sent when the remote peer issues the RSET command. Since RSET is not allowed to fail (according to the protocol), we ignore any return value from user overrides of this method.
Receives the argument of the MAIL FROM command. Return false to indicate to the remote client that the sender is not accepted. This can only be successfully called once per transaction.