Bounce Managemend

Unanswered Question
Dec 3rd, 2008

Hey

I dont know if it there, but would it be helpfull to have a bounce managemend system for outgoing mails, to have a fast view of which outgoing mails are went wrong

I know there is the messagetracking. But here are showing all bounces, even if they are bounced by my apliance (incoming mails)


Best regards

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
kluu_ironport Wed, 12/03/2008 - 16:03

Try using the "Monitor -> Delivery Status" section in the GUI interface. It sheds some light on soft bounces(4##) and hard bounces(5##) statistics.
From that page you can click on the "Help" button on the top right hand corner for more info relevant to that page. Also, on that page, you can click on the destination domains to get more detailed info on that domain.

From the CLI, here are some commands that give you similar results:



Here are some CLI commands that you may find useful in diagnosing the
mail flow on your Ironport appliances:

NOTE: For the commands, you can type "help resumelistener" and get
brieft explanations on what it means and does.

resumelistener [listener_name]

Resumes receiving.
You may specify one or more listener names which will only resume
those listeners.

Use the keyword "all" to resume all listeners.




1. workqueue rate 60

- This will show you the rate of your pending workqueue and mailing
going inbound/outbound in the scanning process for every 60 seconds.

2. tophosts --> Active Recipients(1)

- This displays messages in the delivery queue. Messages here have
already been scanned and is waiting to be delivered.

3. hoststatus --> domain (i.e. yahoo.com, college.edu)

- This provides some information about the mailserver and if they are
up or down.

4. suspendlistener ---> select the inbound listener

- This command should only be used if you see a high queue on one of
your Ironport appliances. A high queue would be over 1000 messages,
sustained for a long period of time. Suspending the inbound listener
on the appliance will allow the mail to process quicker and let the
other appliance assist in the processing of mail traffic. You should
contact Ironport Customer Support at this time so that we can assist in
diagnosing the reason for the workqueue backup.


5. resumelistener ---> select the listener that is in suspension

- This resumes a listener that was previously suspended. Resuming a
listener will allow it to start receiving mail again.

6. suspenddel

- This command allows you to pause delivery of mail to the
destinations. Note, this will suspend all mail delivery, not just one
select domain.


7. resumedel

- Resumes the delivery for all mail.


8. filters

- To delete, activate, de-activate, create new message filters


9. grep

- grep allows you to search for entries in the mail_logs

For example,

grep -i "[email protected]" mail_logs

grep -i "spam" mail_logs

-i means ignorecase


10. delivernow

- Will try to immediately re-send all mail that was previously deferred
and sitting in the delivery queue.

kronoply_gmbh Wed, 12/03/2008 - 16:12

thanks for the good answer.
But it is not that what I mean. I mean a statistik like this

sender was - receive address was - bounce reason how times it is bounced

kluu_ironport Thu, 12/04/2008 - 23:04

You'll need to put in a feature request so that the "Internal users" link [Monitor -> Internal Users], to contain more information.

thanks for the good answer. 
But it is not that what I mean. I mean a statistik like this

sender was - receive address was - bounce reason how times it is bounced
mychrislo_ironport Wed, 08/26/2009 - 10:21

thanks for the good answer. 
But it is not that what I mean. I mean a statistik like this

sender was - receive address was - bounce reason how times it is bounced


I recently revisited this issue (we have outgoing mail distribution) and fact is users are increasingly interested in why mail bounces.

My idea, still WIP, is that when you create your outbound mail, you can custom a X-header, e.g. X-send-type.

Allow the ironport to log extra header information (via LOG subscription settings).

This X-send-type will appear in your regular mail_logs and the most importantly, your *bounces* logs (#5).

Currently configured logs:
1. "antispam" Type: "Anti-Spam Logs" Retrieval: FTP Poll
2. "antivirus" Type: "Anti-Virus Logs" Retrieval: FTP Poll
3. "asarchive" Type: "Anti-Spam Archive" Retrieval: FTP Poll
4. "avarchive" Type: "Anti-Virus Archive" Retrieval: FTP Poll
5. "bounces" Type: "Bounce Logs" Retrieval: FTP Poll
6. "cli_logs" Type: "CLI Audit Logs" Retrieval: FTP Poll
7. "error_logs" Type: "IronPort Text Mail Logs" Retrieval: FTP Poll
8. "euq_logs" Type: "IronPort Spam Quarantine Logs" Retrieval: FTP Poll
9. "euqgui_logs" Type: "IronPort Spam Quarantine GUI Logs" Retrieval: FTP Poll
10. "ftpd_logs" Type: "FTP Server Logs" Retrieval: FTP Poll
11. "gui_logs" Type: "HTTP Logs" Retrieval: FTP Poll
12. "mail_logs" Type: "IronPort Text Mail Logs" Retrieval: FTP Poll
13. "reportd_logs" Type: "Reporting Logs" Retrieval: FTP Poll
14. "reportqueryd_logs" Type: "Reporting Query Logs" Retrieval: FTP Poll
15. "scanning" Type: "Scanning Logs" Retrieval: FTP Poll
16. "slbld_logs" Type: "Safe/Block Lists Logs" Retrieval: FTP Poll
17. "sntpd_logs" Type: "NTP logs" Retrieval: FTP Poll
18. "status" Type: "Status Logs" Retrieval: FTP Poll
19. "system_logs" Type: "System Logs" Retrieval: FTP Poll
20. "trackerd_logs" Type: "Tracking Logs" Retrieval: FTP Poll
21. "updater_logs" Type: "Updater Logs" Retrieval: FTP Poll

Since we :lol: are responsible sender, the bounces log should be relatively small. And it also has some bounce reason included.

You will be easily paste the log via regular awk/perl script. I'd probably send them to mysql.

But I maybe considering using phplist too...

PS. M-series doesn't let us to search custom header field....that's disapointing. because I am sure it got the X-header already.

Actions

This Discussion