grahammm

It is the primary which is generating the IPv6 tag. It is doing this because it received the mail (from the secondary) via IPv6, so this 'screwed' tag is actually the IP address of the system from which it received the mail (the secondary in this case). The colon separated 16bit hex format is the standard way of representing IPv6 addresses in the same as the decimal dotted quad format is for IPv4, and sendmail has adopted the convention of prefixing IPv6 addresses with 'IPv6:' and has done so for quite a few versions.

Ah, so it is the same problem? The original post in this forum was because the mailhost probe failed. Having read the response, I agree that in the headers of that probe that the secondary MX did not show the IP address of the spamcop mailer which sent the probe. The post in help was the result of a spam report where all of the received lines show an IP address, so it did not look to me as though the explanation for the first problem applied to the second - leading me to think it is a different problem. I am sorry if I was wrong. As most legitimate email comes to the primary MX, about 90% of the mail I receive via the secondary is spam so it will be a pity if I cannot report mail received from via the secondary MX.

If I report spam which has been sent via the secondary MX then spamcop reports "No source IP address found, cannot proceed". As far as I can see there is an IP address in square brackets on every received line. One example is http://www.spamcop.net/sc?id=z525021421za7...7f5f6a084f6483z

When sending back the test email sent via my secondary MX, spamcop showed an error The secondary MX sends the mail to my server using IPv6, as the Received headers for the test mail show