Secure EDI [SEDI] transport places the responsibility for security on the endpoint mail clients and presumes that the Internet mail system is not secure. As a result the presence of any mail security “scanning” of the dedicated email account for Export-It SEDI adds no value. In fact, scanning mail sent or received on this email address can only result in mysterious and difficult to identify interference with EDI interchanges.
As proven at sites which use mail scanners (e.g. Symantec Mail Security or MailMarshal), there is a serious concern with the use of a mail scanner on an account carrying EDI message traffic. If a mail scanner is in use then, if it is possible, you should remove [only] the dedicated Export-It email account from those which the mail scanner protects.
Anti-virus protection is not required on messages which Export-It receives (as it will not allow any code to execute) and the outbound features of a mail scanner are likely to lead to mysterious problems unless you use a "Per user customization of all rules" feature to turn off all checking on your Export-It email account. For example, a "Spam Detection" feature is likely to often object to filenames which consist of long, apparently random mixes of letters/numbers/underscores (as used for messages to, and from, Customs or AQIS). And EDI messages do not contain English words which is also likely to trigger “false positives” by SPAM detectors. Also an "Attachment scanning for type, size, content and viruses" feature is likely to sometimes object to the pseudo-random content of EDI files (encryption results in arbitrary binary sequences which may coincidentally be a virus “signature”) or to the file extension (type) which Export-It cannot control and for which the EDI standard has no specification (EDI defines what the content must be, not the filename or type).
If a mail scanner blocks a SEDI message or its attachment then it is discarding an EDI document!
Finally, a "Recursive Archive Unpacking" feature can fall over and cause emails to be lost (we have already seen this at several sites). The end result of mail scanning on the SEDI email account is "erratic" EDI interchanges which usually work fine, but sometimes don't—a situation to be avoided in respect to export permits and declarations. So just exclude the dedicated email account from send and receive scanning when possible. That is simple, safe and effective.
Unfortunately, the remote endpoint (e.g. PRA agencies like 1-Stop or DPI Terminals [ex-CSX]) email addresses are not static. And you do not always receive a reply from the same email address to which the original EDI document was sent. This means that a practice based on “white listing” email addresses is not the best approach. However, when exclusion of the SEDI email account is not possible it can reduce the frequency of problems related to mail scanning.
Here is a list of email addresses from which Export-It
must be able to receive emails:
edi.prod@aqis.gov.au
edi.test@aqis.gov.au
cargo@ccf.customs.gov.au
helpdesk@1-stop.biz
pra_iftera@dpiterminals.com.au
fi.au@babelbridge.com
support@syscob.com.au
syscob@alphalink.com.au
And this is the list of email address to which Export-It
must be able to send emails:
edi.prod@aqis.gov.au
edi.test@aqis.gov.au
cargo@ccf.customs.gov.au
pra@edi.1-stop.biz
fi.au@babelbridge.com
support@syscob.com.au
syscob@alphalink.com.au
Note that these two lists are nearly, but not exactly, identical (1-Stop has differing "to" and "from" addresses). Syscob also suggests that, for “future proofing,” the domains—rather than the specific email addresses—be “whitelisted” to eliminate potential mysterious issues should an address be changed in the future. All of these domains are trustworthy and Export-It is written so as to prevent any malicious attachment from being executed.
Inbound SEDI messages cannot be a security threat as they are received as a MIME text string (which is not executable). Only a message from a legitimate EDI source [see list above] will be examined. Only a message in proper EDI mail format will be processed and processing consists only of decryption and signature verification, if required, followed by extraction of a text [non-executable] attachment (the EDI “interchange”).
SPAM, and other emails from invalid sources or in invalid format, will be saved in the "LOG_EML" subfolder of the Database "server" Folder in the form of text files (with ".eml" extension) that may be safely examined with Notepad. After satisfaction that the message is from a trusted source then it can be imported into a mailer application like Outlook or it can be deleted.
Syscob recommends periodic review, and cleanup, of the "LOG_EML" folder contents.
