SSIS Send Mail task fails on large number of emails - ssis

Pseudo Code
Create list of vendors
Loop through the list of vendors
Create text string of email addresses for this vendor
Create spreadsheet
Send email
End Loop
I use an SMTP connection manager and Send Mail task to send spreadsheets to our vendors.
The SSIS package runs successfully when the elapsed run-time for the package is less than 10 minutes. During the week we successfully send to less than 100 vendors. Occasionally we send to approximately 1,000 vendors. The Send Email task fails because the SMTP server closes the connection after 10 minutes. Our email administrators will not extend the time-out period. I would like to have a single package that handles both small and large mailings.
An error occurred with the following error message: "Service not available, closing transmission channel. The server response was: 4.4.1 Connection timed out. Total session duration: 00:10:00:9968949".
Is there a way to test if the SMTP connection is not open, then use a script task to reconnect? The test would have to go in the vendor loop for each pass.
Any other suggestions how to change the design of the package are welcomed.

Related

Send email from web to server using PHPMailer SMTP protocol

Hi I'm newbie here and i have a simple php form and when user submit it the data will be insert in database and email is send to user using PHPMailer; now mine question is that if i send two consecutively emails that have time difference of 1 minute then why their receiving time difference to user is 15 minutes.
Code will be provided on request.
Thanks.
Might be because of server delay are you using a shared server or maybe you mailer is miss confined

System.Net.Mail.SmtpException : The operation has timed out

I have developed an mvc 5 application from which I'm sending e-mail using smtp. Before sending email I have to export pdf reports in a folder and than attach those reports with email. When I'm sending single email than no problems occur but when I'm sending 2000 or above emails with attaching pdf reports than at a certain time exporting stopped and no email is sending from the application. When I tried to catch the exception I found following exception thrown :
System.Net.Mail.SmtpException : The operation has timed out
Can anyone please help me regarding this issue.
With Regards
Sending a single mail will go very fast, but sending 2000 mails might take time, especially when sending files in each mail
set the timeout higher since there is much more data to process:
smtpClient.Timeout = 5000000;

Trigger iSeries job on new message in data queue

IBM WebSphere MQ has functionality called triggering that allows for an iSeries program to be called when a new message arrives on the queue. Is there a way to allow for the same functionality with a native iSeries data queue?
Yes, set up a CL program that waits on the QRCVDTAQ() API and when a message comes in, call the program, submit a job, etc. The sender would be sending messages that contain the library/program or perhaps even the entire CALL command. You can use QCMDEXC() in the CL to run/submit the program.

Azure QuotaExceededException

When sending a notifications to a notificationhub I receive the following exception:
Microsoft.ServiceBus.Messaging.QuotaExceededException: The remote
server returned an error <403> Forbidden. The maximum number of
Notification operations has been reached or exceeeded. Actual:33360,
Max allowed: 33000..TrackingID55ccd1f7a791-4047-96fd-0d0be2278ff7_g7
Any ideas on how to fix this problem?
What you should keep in mind is that it appears that all operations (not only sending notifications) you do with the NotificationHubClient seems to add to your daily Operations Quota.
I have made the mistake of doing unnecessary registration updates whenever the client logs on to my API.
Device registrations are valid for 90 days, so I'll not have to make any updates unless the registration has/about to expire. (I do save the expire date, which you'll get from the RegistrationDescripton.ExpirationTime, in my user table in my server app for knowing when to do a registration update)

Does every SMTP server that can receive mail have to be able to send failure notices?

I am thinking about implementing my own SMTP server that can receive mail and store it. As this is a small hobby project, I'd prefer to keep the code simple – so, for example, I don't want to implement logic for sending mail. However, the following section from RFC 5321 makes me worry:
The server must give special treatment to cases in which the
processing following the end of mail data indication is only
partially successful. This could happen if, after accepting several
recipients and the mail data, the SMTP server finds that the mail
data could be successfully delivered to some, but not all, of the
recipients. In such cases, the response to the DATA command MUST be
an OK reply. However, the SMTP server MUST compose and send an
"undeliverable mail" notification message to the originator of the
message.
Does this mean that, even if I normally only return 250 OK when I'm sure the message has been stored safely, I am forced to implement stuff for sending failure notices just in case someone decides to send a mail to both an existing and a non-existing mail address at the same time? Is there any way to get around it without violating the standard? If there isn't, how bad would it be to just send back 452 Too many recipients (my RCPT limit is 1, not 100 as required by RFC 5321) whenever someone tries to send a mail to multiple recipients?
In such cases, the response to the DATA command MUST be an OK reply.
However, the SMTP server MUST compose and send an "undeliverable mail"
notification message to the originator of the message.
That seems rather unambiguous to me. If you are to be standards-compliant, you MUST both return an OK response (because the message could be delivered to some recipients) and send failure notification to the originator (because it could not be delivered to other recipients).
On the other hand, your question also mentioned that you will only accept delivery for a single recipient, so a) you've already resigned yourself to not being standards-compliant anyhow by not allowing 100 recipients and b) the failure mode of "mail data could be successfully delivered to some, but not all, of the recipients" will not be possible if there can only be a single recipient.
After re-thinking the situation, I think that it's actually possible to do this in an RFC-compliant way if the server can assure that the mail can be delivered to all recipients at RCPT command time – after all, individual recipients can be rejected when the corresponding RCPT command was received. Of course, this means that the server e.g. has to ensure that enough harddisk space is available for each recipient and the maximum mail size. And a server could just deny mail to a recipient if his current mailbox size plus the maximum mail size is more than the maximum mailbox size.
Of course, the actual implementation is a bit more complicated in order to support concurrency.