I'm using powermta - port25 for bulk mailing. I want it to send bounce mail back to specific bounce back address.
Some servers send for quota or inactive user problem but i want to take all bounce mail report to bounce address. powermta creates logs for bounce mail.
Is it possible to achieve this?
It is definetly possible to send back to bounce emails to spesific email.
There are two types of bounce messages in PoweMTA:
1-) Local bounce message: PowerMTA generates this messages if it gets any bounce message from remote ESP. Almost more than 90% of bounce messages generate this way. In this case you do not have to do anything. PowerMTA will send email that contains bounce information and bounce diagnostic messages to mail from email adress MX.
2-) Transient bounce message: This type of message does not generated by PowerMTA. When PowerMTA connects to remote server to deliver message, remote server accapts email without error than after a period of time, remote server will send bounce message directly to mail from address.
If you have add any configuration to discard the mail from domain. That is all different story.
What you are looking to configure is deliver-local-dsn. This directive instructs PowerMTA whether or not to generate and deliver a
Delivery Status Notification (DSN) for a message.
<domain *>
deliver-local-dsn no
</domain>
The bounce notifications are sent to MAIL FROM address. You can read more about it on Port25 blog post: To where are bounce messages sent?
My understanding is power mta cannot do this functionality.
Related
I am curious to know why Direct mail doesn't support the incoming emails to the same email address used to trigger the notifications. Why do we need to receive on another email?
Is there any architectural limitation to this in terms of security/functionality etc..
Providing email services that includes receiving emails is a different level of service then sending emails and far more complicated internally. DirectMail is a message sending service, not an email server. Alibaba does offer a full email service for its customers in China.
Hosting and receiving emails is far more complex. If you were to provide a service to send and receive emails you have to have an api waiting for an email to arrive, another to retrieve emails from the storage when the user requests, and another to send out the emails.
On the other hand DirectMail just has one service send out either predefined emails that get set up ahead of time or emails that are sent from Function Compute. This way there is no waiting/server overhead, just send and done.
I'm trying to establish SMS sending with Node.js via Clickatell.
I've already tried the way described here: https://www.clickatell.com/developers/api-documentation/nodejs/
And both REST and HTTP requests from here (topics "How do I test my HTTP integration?" and "How do I test my REST API integration?"): https://www.clickatell.com/faqs/product-specific-faqs/platform/integration-testing/
In "SMS integration" area for both HTTP and REST APIs delivery type been set to: "Time critical delivery".
And i'm sending messages to number, that is in "test phones" list.
All the messages, I've sent to the server, are visible in "Reporting" area. But all them are stuck in "Delivered_to_gateway" status.
What i'm doing wrong?
UPD:
So, first message is finaly delivered to cell phone. After almost one and half hour of waiting.
I've also tried to send message to another phone with another cell operator ("Mobile network: Beeline (KB Impuls, VimpelCom)"), and it delivered in a minute or two.
So, detailing my question: it seems Clickatell have some kind of problems with delivering messages to "Mobile network: MTS (Sistema, Prim Telefon)". Can it be fixed somehow?
I built a small server (golang) to grab messages from a RabbitMQ and deliver them to connected browsers via a Websocket.
It works quite well, though has one caveat: the messages are acknowledged when delivered to the browser via the websocket. For most messages that is ok but some messages might be very important. If the user's browser received those but the user didn't SEE the message, it would be lost if the browser was closed or reloaded.
Is there a way to ack a message at a later time based on its message id (from the Delivery struct)?
The use case would be that some messages are acked when the user acknowledges them explicitly and at that point the message id is sent back to the tool to be acknowledged with RabbitMQ.
Even if you can do this, it's bad design.
What happens to the message if the user doesn't see it? Does your web server infinitely hang on to it? Does it "nack" the message back to the queue?
Neither of these options are good.
Hang on to every message, and RabbitMQ will start having issues with thousands of unacknowledged messages from a lot of users. Nack the message back to the queue and you'll thrash the message round in circles, spiking CPU resources on the web server and the RMQ server, as well as network traffic between the two.
The better solution to this problem is to store the message in a database, after pulling it out of RabbitMQ. When it gets sent to / viewed by the browser, update the database to reflect that.
From a yet-unpublished article I've written:
Store the message in a database.
Add a field to the database record that says who this message belongs
to. When the user reconnects later, query the database for any
messages that this user needs to see and send them along at that time.
The full process started above, then becomes this:
User's browser connects to SignalR/Socket.io/Pusher/websockets on web
server
Web server checks a queue for updates that happen during a long
running process
When a message for a logged in user comes in
If the
user is logged in, broadcast the message through the websocket to the
user
If the user is not logged in, store the message in a database
When the user logs in again, query the database and send all waiting
messages
It's what you would have done before the idea of a message
queue came in to play, right? It should be what you would do now that
you have a message queue, as well.
I've just installed hmail on Windows 2012 to self host a mail server. Opened the ports (25, 143 - SMTP, IMAP). Setup auto reply on some test accounts on domain.
I have a strange experience: The first emails I send to the new inboxes from my gmail account get auto-replied. Thereafter any more emails sent are largely not replied (i.e. mostly not replied but occassionaly very late). The hMailServer logs show it found the emails and sending the replies. I tried with my work email account to the new hMailServer inboxes and its the same situation.
I've checked the spam and they only occasionally go in there depending on the auto reply message body. Reverse DNS has been setup by my cloud instance provider.
Not sure whats going on but the hMailServer diagnosis does show red lights against MX records not being found local and internet domains (although internet MX route checking sites give it a green light when checking).
Why is it only sending out first time and then less likely other times.
Ok its because the autoreply function only sends auto replies once per email address. I ended up applying a 'rule' instead to reply and delete the incoming the message to reach the desired behaviour.
The autoreply feature only ONCE per email address PER SESSION. That is to say, when hmailserver (service) is stopped and restarted the cache is cleared and so the first occurrence of the autoreply already sent is forgotten. (Note: it also doesnt autoreply to 'auto-reply' emails as this could cause looping)
I am using Spring JavaMail for my Email communication application. How Can achieve the functionality that when a email delivery fails due the reason of wrong email address?
Achieving this reliably is not trivial. The protocol specs for SMTP in RFC 821 specifies a number of return codes. Notably 550 is what an SMTP server should return when attempting to send an email to a nonexistent address. I say should because most public-facing SMTP servers won't do this - they either quietly accepts the message and then drops it or, if they are a little more good-mannered, accepts the message but sends a "delivery failed" notice back to the sender ("from" address). Public services like MSN and Gmail will also blacklist senders if they send enough emails to non-existing addresses to prevent spam.
The reason for this is to prevent email-fishing and spamming.
So what you can do is to
Check for SendFailedException in your code. This will only work for servers that follow the SMTP specifications and actually send an error code back. Like I said, very few public servers actually do this.
Set up a proper mailbox for the address you use as sender and monitor that inbox for delivery failed notices. Note thought that these need not follow any common pattern, which is why this is non-trivial.
For the email servers that doesn't give any notice, you really have no way of knowing.
This is one of the reasons why companies buy mass emailing services from dedicated providers, since they have all these things already built to measure bounce-rate etc. But even with those, it's never going to be 100% accurate.
These FAQ entries might help as well:
If I send a message to a bad address, why don't I get a SendFailedException or TransportEvent indicating that the address is bad?
When a message can't be delivered, a failure message is returned. How can I detect these "bounced" messages?