TIdSMTPServer - Questions (differences between v9 and v10)

[rlebeau]

Ah ok, so not knowing if my incoming connections might use it, should I then enable it just in case?

That is up to you to decide for your particular use case. I suggest you read RFC 2920 for how Pipelining actually works and rationales behind it.

Is there anything extra I need to do at my end to handle them or does IdSMTPServer break them apart and handle them seperately? (I'm going to assume it probably does)

Pipelining does not change the format of SMTP traffic, it affects only the transmission at the TCP level. Indy doesn't care if the client pipelines its commands or not, since all incoming data is buffered no matter what. Regardless of whether pipelining is used or not, TIdSMTPServer will read and reply to each command individually, though the responses will be buffered if pipelining is active. The use of pipelining simply reduces how many TCP packets are used back and forth, nothing more.

I noticed last night that the IdServerContext that is passed as a parameter has a SMTPState which is set after each succesful stage.

I've put those states into a case statement and so that I can perform SPF checks in there with each stage. Is that a appropriate way forward or is there a better way?

I thought about that before replying earlier. I suppose you could if you wanted to, since the OnSPFCheck event doesn't tell you which command is being validated (even though the triggerer knows that information). When the OnSPFCheck event is triggered for HELO/EHLO then the current SMTPState should be idSMTPNone, and when triggered for MAIL FROM then the current SMTPState should be idSMTPHelo. Those are the only commands that SPF is used for, since they are validating sender identification.