Whatever you are using to submit test messages is not waiting for the
server response between sending commands. This behavior is usually
only found in poorly-written malware. Postfix rejects these messages
when you use the "reject_unauth_pipelining" restriction. http://www.postfix.org/postconf.5.html#reject_unauth_pipelining
As an abstract I can tell you some mailmasters configure their servers to delay at some point, this way they scatter the reception of SPAM or are even able to make a "kind of" SPAM detection feature that pushes spammers to a different SMTP server due to the low efficiency in delivering their SPAM or even the imposibility to do it.
The thing is that those techniques are normally used with non autheticated users so you should not have problems just as long as you authenticate as a user of the system. Nevertheless it looks like this provider of you is applying this technique in every case so you have two options: change to a different SMTP server (none of mine is giving any problem in this way), change the source code to insert a sleep command, or a SMTP "NOOP" command (this would be more ortodox) where your SMTP server requires it. Mailmasters use this at their own pace so you will have to experiment.
Putting this the other way around it could be said that an SMTP server does not have the obligation of attending SMTP clients that write all the SMTP protocol in a raw, in fact not all of them do....
I found the key literature about this matter in this RFC document: http://tools.ietf.org/html/rfc2920 we will try to accomodate the program logic to this sort of behaviour.
Last edit: 33HOPS 2014-07-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In regards to Google Mail it does not seem to be "speaking" SMTP but probably a variation. The reasons could be that Google Mail prefers its own clients though I have not really deepened into it so I'm just speculating. Try different SMTP servers till you find one that speaks RFC SMTP and is less restrictive or setup your own, its fairly easy (no more than 10 min.).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I extracted this text from the RFC 2920 document that is self explanatory:
When a client SMTP wishes to employ command pipelining, it first
issues the EHLO command to the server SMTP. If the server SMTP
responds with code 250 to the EHLO command, and the response includes
the EHLO keyword value PIPELINING, then the server SMTP has indicated
that it can accommodate SMTP command pipelining.
In your case the SMTP response from the server is declaring it accepts pipelining but it is not honouring this declaration some lines ahead. probably it is just a way of confusing spammers.
...
Well, reading the SMTP conversation with calm you can see the server declares PIPELINING thus telling us it accepts many commands in a TCP row. In the end the server is quitting with a 4.5.X response and telling you PIPELINING is not accepted for the recipients you are setting.
I think your problem has to do with the combination of USR/PWD "mail from:" and "rcpt to:".
Last edit: 33HOPS 2014-07-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We do not intend to do any particular development to work with any particular brand. If they comply with the SMTP RFC + PIPELINING specifications great, if not I suggest you use a different SMTP server that does comply with this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I launched:
./xsibackup --backup-point=/vmfs/volumes/backup --backup-how=hot --backup-type=custom --backup-vms=MACHINE1 --mail-from=sender@domain.com --mail-to=mymail@domain.com --smtp-srv=smtp.mandrillapp.com --smtp-port=25 --smtp-usr=sender@domain.com --smtp-pwd=JUSTLETTERSAPIKEY --subject=ESXiBackup --test-mode=true
And i get this log:
Opening port 25 for SMTPout service...
220 smtp.mandrillapp.com ESMTP
250 ip-10-82-8-68
250-ip-10-82-8-68
250-PIPELINING
250-SIZE 26214400
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
334 VXNlcm5hbWU6
334 UGFzc3dvcmQ6
235 2.7.0 Authentication successful
250 2.1.0 Ok
403 4.5.0 mymail@domain.com: Recipient address rejected: Improper use of SMTP command pipelining
454 4.5.1 Error: no valid recipients
221 2.7.0 Error: I can break rules, too. Goodbye.
Firewall rule SMTPout closed.
I don't now if the problem is in the xsibackup script or in the mandrill side., but mymail@domain.com is completely valid and able to receive mail.
Can you check?
I found:
Whatever you are using to submit test messages is not waiting for the
server response between sending commands. This behavior is usually
only found in poorly-written malware. Postfix rejects these messages
when you use the "reject_unauth_pipelining" restriction.
http://www.postfix.org/postconf.5.html#reject_unauth_pipelining
When testing, I find it convenient to use a command-line tool
designed for SMTP such as mini_sendmail.
http://www.acme.com/software/mini_sendmail/
Maybe this can help, mandrilapp is operative, so, seams that is a protocol negotation error.
With a google smtp auth text plain server i had this:
Opening port 25 for SMTPout service...
220 mx.google.com ESMTP c9si321378wix.3 - gsmtp
250 mx.google.com at your service
250-mx.google.com at your service, [my ip]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 CHUNKING
503 5.5.1 bad sequence of commands c9si321378wix.3 - gsmtp
502 5.5.1 Unrecognized command. c9si321378wix.3 - gsmtp
502 5.5.1 Unrecognized command. c9si321378wix.3 - gsmtp
250 2.1.0 OK c9si321378wix.3 - gsmtp
250 2.1.5 OK c9si321378wix.3 - gsmtp
451 4.5.0 SMTP protocol violation, see RFC 2821 c9si321378wix.3 - gsmtp
Firewall rule SMTPout closed.
O.K., one by one please ;-)
In regards to your first post this URL will probably give you a better explanation of whats happening: https://www.bfccomputing.com/reducing-spam-with-smtp-validation-on-postfix/
As an abstract I can tell you some mailmasters configure their servers to delay at some point, this way they scatter the reception of SPAM or are even able to make a "kind of" SPAM detection feature that pushes spammers to a different SMTP server due to the low efficiency in delivering their SPAM or even the imposibility to do it.
The thing is that those techniques are normally used with non autheticated users so you should not have problems just as long as you authenticate as a user of the system. Nevertheless it looks like this provider of you is applying this technique in every case so you have two options: change to a different SMTP server (none of mine is giving any problem in this way), change the source code to insert a sleep command, or a SMTP "NOOP" command (this would be more ortodox) where your SMTP server requires it. Mailmasters use this at their own pace so you will have to experiment.
Putting this the other way around it could be said that an SMTP server does not have the obligation of attending SMTP clients that write all the SMTP protocol in a raw, in fact not all of them do....
I found the key literature about this matter in this RFC document: http://tools.ietf.org/html/rfc2920 we will try to accomodate the program logic to this sort of behaviour.
Last edit: 33HOPS 2014-07-30
In regards to Google Mail it does not seem to be "speaking" SMTP but probably a variation. The reasons could be that Google Mail prefers its own clients though I have not really deepened into it so I'm just speculating. Try different SMTP servers till you find one that speaks RFC SMTP and is less restrictive or setup your own, its fairly easy (no more than 10 min.).
I extracted this text from the RFC 2920 document that is self explanatory:
When a client SMTP wishes to employ command pipelining, it first
issues the EHLO command to the server SMTP. If the server SMTP
responds with code 250 to the EHLO command, and the response includes
the EHLO keyword value PIPELINING, then the server SMTP has indicated
that it can accommodate SMTP command pipelining.
In your case the SMTP response from the server is declaring it accepts pipelining but it is not honouring this declaration some lines ahead. probably it is just a way of confusing spammers.
...
Well, reading the SMTP conversation with calm you can see the server declares PIPELINING thus telling us it accepts many commands in a TCP row. In the end the server is quitting with a 4.5.X response and telling you PIPELINING is not accepted for the recipients you are setting.
I think your problem has to do with the combination of USR/PWD "mail from:" and "rcpt to:".
Last edit: 33HOPS 2014-07-30
Read this: http://33hops.com/blog_xsibackup-smtp-client.html
I'm going to check everything, thank you for your time Daniel!, great Job and congratulations for your development!.
Thank you, please leave a review https://sourceforge.net/projects/xsibackup/reviews
Last edit: 33HOPS 2014-08-03
Here is the google mail servers:
https://support.google.com/a/answer/176600?hl=en#
It will be great if you support the last one (smtp restricted one)
I'm not able to modify the xsibackup,
MandrillApp settings will be great, because is an often used service too
Free account: https://mandrillapp.com/settings
SMTP & API Credentials
Host smtp.mandrillapp.com Copy
Port 587 Copy
SMTP Username dev.admin@shoptimix.com Copy
SMTP Password any valid API key
Thank you Daniel.
Fran
We do not intend to do any particular development to work with any particular brand. If they comply with the SMTP RFC + PIPELINING specifications great, if not I suggest you use a different SMTP server that does comply with this.