Is there a way to insert a programatically created header?

[jasongurtz]

We have the situation were we are signed up for feedback loops, but the recipient data is elided by the ISPs due to privacy concerns. They are also smart enough to elide the recipient data included in custom X-Headers that we add to all outgoing mail.

My idea is to add a custom header with the recipient data encoded in e.g. SHA1 so that the feedback loop software (and casual observers) will not know of or elide the recipient data from the ARF feedback loop responses.

Can this be done on the Ironport using e.g. perl scripting? Or am I going after the wrong thing?

[Andrew Wurster]

no, unfortunately you can not do this. you could perhaps use a message/content filter to strip this header information from replies entirely...

you can also use DKIM to sign the message and guarantee it's authenticity upon delivery. or secure the entire message with an IEA or the CRES and hid it altogether.

[jasongurtz]

I don't think you understand the issue here. We WANT this information. We already sign all outgoing mail with DKIM/Domain Keys, have proper SPF/Sender ID records, have proper entries in the PBL at Spamhaus, and are included in the whitelist at http://www.dnswl.org/. Conservatively, our sending posture is probably better configured than 95% of all other small and medium sized businesses.

This is specifically NOT an issue with verifying authenticity. It is an issue with our sender compliance and ensuring that our sending reputation and sending ability is not damaged by stupid moron recipients at large free webmail providers and ISPs. When we get notification from one of these feedback loops it means the recipient has clicked the "This is Spam" button in the web interface of their email. Please understand we do not send any marketing email. We are a utility company and send Corp. B2B, personal, or transactional email only. There are no mailing lists here at all. In all cases thus far, the "Spam" button was clicked in response to receiving a personal email from a friend who works here or to a password reminder email from our bill payment system *which they initiated*!

Since the recipient data is redacted from the headers included in the notification it is much harder and more time consuming with the Ironport/Exchange environment to find who the recipient is (using the Message-ID which is perhaps days/months old).

If we can embed the recipient information in the email headers in such a way that it escapes redaction by the feedback loop systems we can immediately see who the moron is and take appropriate action and notification steps (via snail mail).

REQUEST:
Add a plugin or API system to AsyncOS so that customers can add their own features. I can think of several others besides this one.

[Andrew Wurster]

i am sorry if you feel i misunderstood your original request. there were a lot of combined requirements and i believe i took them all into consideration.

and yes, sure the request for an API makes sense. go ahead and send your needs to us!

http://tinyurl.com/mm8r26

you can certainly insert headers into the original receipts and/or body values into system-generated notification emails - just not in SHA encoding...

check out 'Table 13-3 Anti-Virus Notification Variables' in the AsyncOS userguide. variables like $To and $From are accessible for post-scanning insertion into headers which may help you in your task.

all the best,

andrew

[mychrislo_ironport]

I had a similar issue with the orginal poster.

Want to stick a custom header into the mail headers.

We do that at the sending mechanism.

We insert X-MAIL-LABEL into every mail we processed, this is just to catch some instant bounce (logged to bounces log). And instruct ironport to log X-MAIL-LABEL. So that we can retrieve the log, data mine it and store it as we wanted.

Our sending mechanism is using shell script. If your client is java/php, I think the same can be done.

X-MAIL-LABEL:

That base64string is generated by using a snippet of perl code (or openssl) in the very same Unix host we "craft" the outgoing mails.

[jasongurtz]

Yes, a good idea maybe. In this case we have individuals and the various servers all relaying through exchange as the pinhole out to the Internet. I could setup a UNIX box running MIMEDefang or something in between it and the Ironport. Seems a shame though for the extra complexity it introduces.

But it's either that or write an event sink.

Sorry for the intense skepticism, but has anyone ever submitted a feature request as described in the KB and actually seen Ironport implement it? Past experiences with other large companies suggests slim to nil chance and thus a waste of time.

[meyd45_ironport]

You could put a header in all messages, then when you receive a FBL complaint
you lookup the MID with findevent to through the GUI message tracking

blah: if(true) {
insert-header("X-Trace", "$hostname/$mid");
}

I estimate that around 20% of FBL traffic from AOL is not spam.

James

[Andrew Wurster]

jgurtz -

i'm sorry you feel that way about the feature requests. i hope that same experience does not correlate directly for ironport or cisco. that said, asyncos is not equivalent to windows or os x or ios, so i think regular input like yours is held in pretty high regard. think of it like winning a raffle at a local fundraiser event, rather than your state's lottery prizes...

if you're ever dissatisfied with the product or services you pay for, we need you to be vocal about it with your account team and in the customer feedback surveys after your support cases are closed, so the right people know about it.

the only thing we can do in life is try our best.

sincerely,

andrew