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
Category:NFC
(section)
Category
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 NFC Project KT PART 1. Dated 13 Nov 2024 - Tetra Support Staff - Narendra Chall== {{#ev:youtube|xuUwNHrmbpY|640}} '''Video summary:''' "Narendra NFC KT 1" -- an English-language KT session covering the NFC (National Fertilizers Corp-type client) Zimbra mail environment, deployed at three locations: Hyderabad, Kota, and JTC, migrated from Rediffmail to Zimbra Network Edition 10.0.0.2. Incoming mail flow is: KSMG (a secure mail gateway that applies spam/allow-block rules and can bounce mail) -> IMSVA (Trend Micro InterScan Messaging Security Virtual Appliance, doing further per-IP/domain/account filtering) -> a Postfix daemon pair -> the MTA -> the destination mailbox; every user also has a separate archive (AR) account that a linked archive server populates for all in/outbound mail. Hyderabad runs four physical servers -- two paired mailbox/MTA/proxy servers (PCS cluster + fencing, so the standby takes over automatically if the active one fails), a shared pair of NAS storage boxes (primary/secondary) behind them, a dedicated AR server, and an internal mail gateway serving ~18-20 internal domains (with manual internet-relay as a fallback if that gateway fails). Kota and JTC mirror this setup but use DRBD replication instead of PCS/NAS, which the presenter flags as the single most important thing to monitor: DRBD sync must be checked daily, since if the primary fails while sync is only partially complete (e.g. 60%), the un-synced portion of data is permanently lost on failover. All outbound internet mail from Kota/JTC users must route through the Hyderabad MTA hub -- intra-site mail doesn't need this. Mailbox sizing (Class of Service) is tied to employee designation/grade (e.g. 2GB/7GB/12GB/18GB tiers), and user creation is scripted to auto-provision the matching archive account and notify designated stakeholders. Common support scenarios covered: 90-day mandatory password rotation and reset requests, a 30MB outbound attachment size cap, password-protected PDFs being blocked/bounced on delivery (unprotected PDFs pass), mailbox quota checks for "can't send mail" tickets, and a protected "public circular" dynamic distribution-list folder that only one admin account can modify.
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)