Terms and Conditions


This applies to any domain that resolves to an IP address of the BGC Corporate network and the BGC Corporate network itself which has the IP addresses from to (or CIDR

Internet Standards

Any one connecting to the BGC network should do so with intent of cooperation and interoperability. Requests For Comments (RFCs) published by the Internet Engineering Task Force are the main source of standards which must be followed for the Internet to be secure and for it to work.

World Wide Web

Our WWW content should comply with the requirements of the W3C. It may also include JavaScriptTM or JavaTM.

It is also a requirement that BGC sites produce usable content with any standards compliant browser such as Lynx to permit access to our sites by the disabled.

Should any BGC site fail in these requirements then this should be reported:


BGC require the use of the Simple Mail Transfer Protocol (SMTP) when sending email to our network. In order to protect our network we will check that SMTP is being used.

The SMTP is described in these RFCs: 821, 1035, 1123, 2142, 2821, 5321.

In accordance with the SMTP we provide the required mailbox names: –

In addition to these our SMTP replies include a URL for trouble reporting that can facilitate identification of the
problem. The IP address and time stamp are sufficient to identify an individual
SMTP transaction. This link provides in the subject of the locally generated
email for postmaster@bgcaus.com the following: –

  • The hostname of the sending server if in the Domain Name System (DNS);
  • The IP address of the sending server in [ ] ; and
  • The time the email was rejected in GMT Zulu format.

This does not require working email from the sending end. All that is required is that the mail server that is attempting to send the email includes our reply in its non-delivery message.


Prior to Explicit Congestion Notification (ECN) when a network was congested packets would be dropped. This triggered a back-off, but it did not work as dropped packets still needed to be re-sent. In the old days of hubs or 10Base-2 in small LANs well below capacity such packet loss could tolerated as data could be resent, however in a wide area network that is approaching capacity this re-sending of lost data is catastrophic. When such a link was red lined the resulting packet storm results in very poor network performance, but uses maximum bandwidth. This resulted in Denial of Service (DoS).

ECN is necessary for non trivial networks to avoid collapse should the link capacity be reached. ECN achieves the rate back off without the destructive data loss and the need to re-send data. Space has been reserved in the Internet Protocol (IP) for this since 1981 (though it was called Type of Service and Reserved for Future Use) and Differentiated Services Code Point (DSCP) both of
which are required for Quality of Service (QoS).

ECN became standard in 2001 with RFC 3168 (updated in 2006 RFC 4774) and ECN is backwards compatible with the RFC 791 Internet of 1981. ECN has been in Microsoft since Vista and Server 2008 and since Apple OS X, Cisco IOS 12.2(8)T, Sun Solaris 9, IBM AIX 5.1, GNU/Linux 2.3, *BSD and is in most other systems with TCP/IP networking.

As the popularity of Microsoft on the Internet grew after the 80s so did the requirement for the use of firewalls. Some non-conforming firewalls, however erroneously drop packets when reserved bits are set. If however they comply with RFC 791 and the end point complies with RFC 3168 or 4774 then the end point could then use those reserved bits to back off without dropping the packet.

Please be advised that BGC employs Explicit Congestion Notification (ECN) to protect it’s Internet services from collapse due to congestion.


The BGC email system is provided to facilitate communication of specific enquiries with our business partners. BGC will not accept its email system being rendered useless by allowing it to be stuffed with useless email.

You may not send or permit the sending of any: –

  • Unsolicited Bulk Email (UBE);
  • Unsolicited Commercial Email (UCE);
  • Unsolicited Religious Email (URE); or
  • Unsolicited Political Email (UPE);

to any BGC email address.

You may only email specific recipients in relation to your enquiry, however automated mailing for diagnostic purposes such as RFC compliant non-delivery messages and relay testing for the purpose of spam prevention are permitted.

BGC does not solicit useless email and will take necessary action to protect its network should such email be attempted.

Relaying Spam

You should avoid sending non-delivery messages to the Internet (backscatter relay) by checking that you will be able to deliver the mail during the SMTP conversation, but should you later find out that you will not be able deliver the message after you have accepted it then you must not relay the original email body or attachments. These requirements also apply to vacation or out of office replies.

Automated backscatter bounces to the apparent sender that do not provide original header can only be regarded as UCE/UBE as the only possible purpose they can serve is to promote a particular mail filter product.

You may not relay other peoples mail to BGC.


BGC require that the Internet Message Format be used for email that is to be sent to our network. This describes the US-ASCII fixed 78 column plain text that is suitable for sending to different machines including UnixTM Systems. (Note that the 78 column format allows for original 72 column text to quoted up to 3 times with “> “.)

The Internet Message Format is described in these RFCs: 20, 822, 2822, 5322.

If attachments have been requested by BGC then these can only sent with Multipurpose Internet Mail Extensions (MIME) or S/MIME.

Multipurpose Internet Mail Extensions are described in these RFCs: 2045, 2046, 2047, 2048, 2049.

S/MIME can provide electronic clear signing which can detect any modification, yet still enable content to be examined for safety and policy compliance.

If a character set suitable for SI or metric units of measure is required then 8bit western ISO-8859-1 or ISO-8859-15 should be used. If western or US-ASCII is unsuitable for the language used then 8bit UTF-8 plain text is preferred.

You may not use additional encoding such as .zip or winmail.dat (ms-tnef) as the only possible purpose of such cloaking could serve is to conceal the content of the email.

If BGC has requested Microsoft Office attachments then you must send “Word/Excel/PowerPoint 97-2004 Document (.doc, .xls, .ppt)” versions as we do not have Microsoft Office 2007 or 2008 available. (You could also use Microsoft .rtf or .slk, but these must not have .zip or winmail.dat (ms-tnef) encoding.)

Unsolicited invalid (gobbledygook) email will be reported as spam.


The BGC Corporate network is operated in the state of Western Australia via a Carriage (or Telecommunications) Service and as such we have protection under both state and commonwealth law.

  • 440A Unlawful operation of a computer system
  • 477.3 Unauthorised impairment of electronic communication
  • Spam Act 2003

Unauthorised access

You may not use any service that normally requires authentication if you have not been authorised to use such a service.

Reckless impairment of electronic communications

Failure to follow Internet standards and protocols could only reasonably be expected to cause disruption of service and as such would be a reckless act.

When entering the BGC network please take care to ensure that Internet standards are complied with.

Spam Act Reporting

Spam to our email (an Australian link) is reported to the Australian Communications and Media Authority (ACMA) in addition to a number of filtering and listing services.

Spam that originates from Australia is also reported to the ACMA in accordance with their procedures for reporting Australian spam.


Loosely based on: http://www.4qd.org/philos/spam.html

Purchase Order Terms and Conditions

Our Purchase Order Terms and Conditions document is available for download here.