Sorry, let me elaborate a bit : We plan to have an interim setup where emails sent to us & HQ (in another country) has a global format ie a_u...@xxx.com.
Currently emails sent to our HQ are in the form a_u...@xxx.com.au & to us are in the form a_u...@xxx.com.nz. So the plan (which is an interim measure as we'll plan to merge our email server to HQ's email server/LDAP at a later stage) is : when there are emails sent to .com that are meant for us (in nz), they will be sent to to our HQ's Proofpoint (which scan for malware, spam, rules) before these emails are being rerouted from our HQ's ProofPoint to our email server via public Internet (as we don't have a point to point WAN link with our HQ) without going through our (nz) ProofPoint. Our local Proofpoint won't scan for malware, spam, rules for these forwarded emails from our HQ's ProofPoint. Our local ProofPoint will only scan for emails sent to us addressed to a_u...@xxx.com.nz On 7/28/16, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote: > >> On Jul 27, 2016, at 11:24 PM, Roger Goh <gpro...@gmail.com> wrote: >> >> Can source (ie smtp.zzzbank.com.au & srvm02.zzzbank.com.au below) >> & the IP addresses be spoofed? > > Your question is not sufficiently clearly stated. > >> Received: from smtp.zzzbank.com.au (10.98.2.87) by >> ZZZWVEXC01ZZ.bbb.com.au >> (10.9.95.37) with zzzzz SMTP Server (TLS) id 24.3.271.0; Wed, 20 Jul >> 2016 >> 17:07:22 +0800 >> Received: from pps.reinject (srvm02.zzzbank.com.au [127.0.0.1]) by >> srvz02.zzzbank.com.au (8.15.0.59/8.15.0.59) with ESMTPS id >> u6K97Jk3033821 > > When "ZZZWVEXC01ZZ.bbb.com.au" is receiving the inbound email, the source > IP address can only be "spoofed" by an "on-path" man-in-the-middle > attacker, > able to intercept network packets directed to "10.98.2.87", and thus > maintain > a TCP session for the transmission of email. > > Absent DNSSEC, the same MITM attacker may be able to forge DNS replies (if > also "on path" between the receiving SMTP server and the nameservers it > uses to resolve "10.in-addr.arpa" and "zzzbank.com.au". > > On the other hand, anyone can create a message in which the above > "Received:" > headers appear. What a forger can't easily do is ensure that such headers > are the topmost trace headers. When the forger transmits the message, the > nexthop receiving system will record the forger's network address as the > sending system in the topmost trace header. If that origin is not > trustworthy, > then you can't believe the validity of any trace headers it sends. > > -- > Viktor. > >
