Yes, that’s a wise expected behaviour. Just tested with my client Apple mail I received a bounced mail and a regular one
But why does 4D reject with an error? Users dont care if an address is wrong amid tenth of others!
Couldn’t test Apple mail, but the iPhone, and Outlook behave like 4D:
You can not send an e-mail when one of its recipients is malformed.
The iPhone asks you “Do you really want?” but when you say “Yes” then you get an error that the whole e-mail cannot be sent and has been moved to the Drafts folder.
In Outlook, you get an error message immediately when you hit the “Send” button, and the whole e-mail will not be sent.
What you describe here is the “client level” behaviour decided by its manufacturer.
As a developper, the point of view is a bit different: 4D is a programming tool. Since the SMTP server is able to reject invalid addresses, one by one, 4D should stay in its own playground and send whatever the user decides to send.
4D should NOT reject the whole operation “at the door” of the SMTP server. Avoiding to send should be done at the user level.
Today, I was forced to write an extension of my code to extract invalid addresses.
I don’t have an opinion whether one way is better than the other, but to play the devil’s advocate, when you say…
…who is the “client” in this context, 4D (the command itself) or the 4D application (the code that is written using the command) ?
But I feel that weeding out “malformed recipients” is not the right way (sorry for that), because an address might be fully RFC compatible but invalid.
Should not the solution be to iterate over each recipient and catch each error?
Of course, the command is not quite ready for that solution either, because now you can not use the “To” or “Cc” headers. Perhaps what we need is an option to specify the “To” or “Cc” headers just for cosmetic purposes and not add them to the recipients list.
I agree with Bertrand here as we do a lot of emails. However we seldom encounter this problem as we do validate (minimally but effectively) addresses before importing into 4D records and we seldom send to multiple recipient anymore.
But we have a system that diagnoses the bounce backs and that gives us much more information.
4D therefore for my purposes should generate an error but still send out the email to all recipients and let the SMTP server decide. Or at best remove the “bad” address from the list and send to all other recipients.
But catching and repairing or flagging the bad addresses should avoid this problem. It has for us 100%.