›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

SRP Mail utility and Win10/11, OLE, .NET V4.8, SSL/TLS, x32 vs x64

KDIVKDIV
edited October 2022 in SRP Mail Utility
Given some of the recent changes in o365/.NET/32 or 64bit architecture/OLE, I am wondering if SRP's mail utility handles the current issues with email utilities. Lots of discussion on RTI's forums regarding some of the recent changes and I believe the "end game" is 1) if OI v9.x x32 use RTI_CDOMail and 2) if OI v10 x64 use RTI_SendMail; which can be maintain, but why? Shouldn't have to deal with this issue but I guess if MS sneezes, we have to jump, ugh. I understand a lot of stuff was re-developed by MS (o365, etc) and SRP's mail utility was re-written after v2.2 (ish) which uses .NET vs OLE or something like that. Anyway, my question(s), can I use SRP's mail utility with TLS, in Win10 or Win11 to about 1000 (or more) recipients in OI v9.x (x32 or x64) and in OI v10.x (x64 only - I believe)? Can I add "attachments" in various file formats (.pdf/.txt/.csv/etc.) to the email that is sent, can I add an image to the bodytext in the email? Some of the recipients will be a mobile phone# plus the mobile carrier's domain requirements that I want to send a TEXT message sent using someone's mobile# programmatically in OI. Please advise.

Comments

  • KevinFournierKevinFournier
    Sadly, the future of mail handling is to utilize a third party service. SRP Mail was written when there no other options for OI programmers. We've kept it up to date as much as possible, but there may eventually come a day when simple SMTP is put to rest. After all, super easy access to sending gobs of emails is why our inboxes are full of spam.

    To answer your question, SRP_Mail supports TLS and will send as many emails as the email server permits. SRP_Mail is a simple communication tool. Any error you tend to get back is not from SRP_Mail; it's from the email server itself. Many ISPs have monitors in place that will flag you as a spammer if you push too many emails too fast, at which point, no emails will be sent.

    As for attachments, you can attach whatever you want, but the email server reserves the right to reject them. GMail can be pretty strict about this with default settings, and will reject all kinds of attachments that have even a whiff of potential at executing code.

    Images in the body can be done using HTML, but again, it's up to your email server as to what images are allowed and how. It's also up to the end user's email software as to how the images are displayed.

    SRP_Mail cannot send SMS text messages, nor do we have a tool for doing this. You'll want to look into a third party service to provide this functionality.

    In the end, I hope you can see that email is very server driven. You actually have very little control over a lot of things. Think of SRP Mail as making a kind request to your email server while you cross your fingers in anxious anticipation. :)
  • KDIVKDIV
    Thanks Kevin, appreciate the information, albeit a bit disappointing. I am trying to determine a company standard for sending emails and texts, we send a lot of email campaigns and texts. Currently, everyone is using a different mail utility in OI, so you can image the chaos. I have been using SRP Mail utility since SRP developed it (2005ish?) and wanted to use it as the standard, but we need the option to text. Do you know if RTI_CDOMail currently have an option to send texts? I can enter a mobile#:'@':tmomail.net in the "To" line in Outlook (2019) and click SEND and the text message is sent and received. So was hoping there was a way to send mobile#(s) as params (array) to SRP_Mail and the mail utility would send text messages. I have not used all the bells and whistles in the Mail utility so was hoping this was an option that I just had not explored before. Looks like I need to see if I can do this in RTI_CDOMail or as you mentioned 3rd party tool. I think someone mentioned Twilio, but there needs to be discussion before using a 3rd party tool due to security concerns. Will research RTI_CDOMail and the OI forums.
  • DonBakkeDonBakke
    I take it you are asking if SRP Mail or RTI_CDOMail can send texts using the SMS or MMS protocol rather than the old fashioned way of sending a formatted email address to the appropriate wireless carrier. The answer is no because email uses a different protocol (SMTP in both of the above cases). You need to work with an API that directly or indirectly communicates using SMS or MMS. The direct approach is to go through a GSM gateway appliance. The indirect approach is to integrate an API from an SMS solution provider. The latter is the typical solution used by small to medium sized businesses.
  • KDIVKDIV
    edited October 2022
    "GSM gateway appliance" - yes, its all starting to point in that direction, but currently, the "appliance" is "in-discussion". I have researched other options but it's like re-inventing the wheel and not really interested in that aspect. Thanks for the info.
  • KDIVKDIV
    edited October 2022
    Don - as a work-around, until we can procure a gateway appliance and/or API development, can I send a text via SRP mail the "old-fashion", by providing a mobile# and mobile carrier domain? i.e. To: 4154547188@tmomail.net and sending to SRP_Send_Mail via passed params #3/#4/#5? For now, this will be just a simple ping to a user letting them know, process ran and completed, really doesn't need anything more than boolean logic, 1-successful run or 2-failed. As I can packaged up the contents of the FATAL error in a logfile that I can reference to the user in the text message. Just a thought. TIA.

    equ SRPMail_To$ to 3
    equ SRPMail_Cc$ to 4
    equ SRPMail_Bcc$ to 5
  • DonBakkeDonBakke
    As long as your email service provider will still support SMTP emails then that should work.
  • KDIVKDIV
    Yes, I will need to confirm, but so far, based on the mobile carriers I will be using, does allow, but at some point it will stop and will need to develop our own API or use a 3rd party. Thanks again.
Sign In or Register to comment.