Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
TetraWiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Training 2022 Linux team/
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Training on Mail Sending & Receving Problem & Bouncing Problem Part-1 . Dated 01 Feb 2022 - Tetra Support Staff - Biswajit Banerjee== {{#ev:youtube|mc7qlMP9GeM|640}} '''Video summary:''' "Training Sending,Recieveing Bouncing part1" -- a clear, well-structured English-language training session on the methodology for diagnosing mail sending/receiving/bouncing issues, using SysNet Global as a running example. The central teaching point: a support engineer should NOT jump straight to logging into the server -- first understand exactly what the customer is reporting (not receiving mail vs. sending bounces vs. sent-but-not-received-and-not-bounced are three different problems needing different investigation paths) and understand how mail is supposed to flow for that specific domain, since 40-60% of issues can be diagnosed or at least narrowed down without ever logging in. Walks through the actual discovery process: use `host`/`nslookup` (both Linux and Windows CMD demonstrated) or a tool like MXToolbox to find a domain's MX record and confirm where mail is actually supposed to land; check whether port 25 (SMTP) on that mail server is even reachable via telnet, since a dead SMTP port typically means the whole world can't reach that server (a different problem shape than one-off delivery failures); and cross-check by asking the customer to test sending to an external address like Gmail to isolate whether the problem is inbound-only, outbound-only, or both. Only once external factors (DNS/MX/port reachability) are ruled out does the engineer log into the server itself -- at which point the priority is knowing what platform is running (Zimbra/Postfix account for the large majority of environments, with a small remainder split between Kloxo -- a free cPanel-like panel for small/shared customers -- and a handful of consulting-only environments) and reading the relevant logs. Ends mid-session (to be continued in a Part 2) citing time constraints, having covered the discovery/triage methodology but not yet reached the actual server-side log-reading portion.
Summary:
Please note that all contributions to TetraWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
TetraWiki:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)