Hey, Nick.
I spent some time poking at this
with a stick.
Since I just use IMail as a
gateway so that I can use Declude... I've had no use for IMail
mailboxes or forwarding, so it was all new to me.
The real answer is that you
should lobby Ipswitch to implement that sender re-writing in their
forwarding (what the heck... all of SPF plus the bells and whistles
while they're at it). If you can garner support from other people to
make the same request, all the better.
You can also tell your client
"Sorry, Adelphia controls how [EMAIL PROTECTED]
email is moved around and since the destination you want adheres to
Adelphia's wishes, I can't forward it. However, if you do have Adelpha
forward the mail to me, I can filter out the spam and viruses, and you
can use POP/IMAP to retrieve the good mail from my server."
As a new policy, you would want
to double-check that any mailbox for which you do forwarding doesn't
send mail from some domain that has a tight SPF, or whomever you're
fowarding to (e.g. surfglobal.net) will see you as a spammer.
If you want to perservere and
build your own forwarding system, what I found was that:
1) Just doing a "forward" action
on a mailbox was functionally identical to making an IMail mailbox with
a rule that says "if sender email contains '@'
then forward the mail to [EMAIL PROTECTED]" and that this
forwarding violates SPF for a domain like Adelphia.com.
2) It's not easy but it's not
impossible to instead use a Program Alias instead. That program alias
would call a batch file with optional parameters (let's say we provide
two in our configuration). That batch then receives a %3 parameter
added on that contains a tmp*.tmp filename which is really a D*.SMD
file with a different name in the \imail\spool folder.
The first thing the
batch would do is some sanity checks.
You would have to avoid mail
loops and other badness by making sure that this is a message that
should be forwarded, e.g. not a bounce message from whomever you're
forwarding messages to! If it is crap, it should delete the tmp*.tmp
file and exit.
The second thing the
script would do is manufacture a Q*.SMD file.
Since you've already got the
D*.SMD file, if you can just manufacture an appropriate Q*.SMD file,
you can have IMail re-send the message while passing on the complete
headers and without having to do any editing of the D*.SMD file
although there probably are useful smarty pants edits (e.g. changing
the "From:" line to something like "From: [EMAIL PROTECTED] on
behalf of [EMAIL PROTECTED]" or inserting the frills Received-SPF:
header).
Here's the format of the Q*.SMD
file, as per the venerable R. Scott Perry:
The "R" recipient row would then
be the 3rd party destination, e.g. [EMAIL PROTECTED]
In my testing it seemed that
also using the "N" original recipient row to the sender field would
preserve the "Reply-To:" as the original sender but that may have been
an artifact of bad thinking on my part (you'd best extract the original
Declude spoolname from the tmp*.tmp file and use that to extract the
MAILFROM for that message from the sys*.txt file! [To get that, you
must use the "XSENDER ON" option in your global.cfg file])
The "Q" file row defines the
fully qualified name of the tmp*.tmp file and doesn't have to be D*.SMD
format; you can just specify the tmp*.tmp file here.
The "H" host row is just your
normal name for the IMail host.
The "I" guid row contains the
long id number that IMail will use in the sys*.txt file to identify
this message. Ideally this would be unique every time; however for
testing you could write out the same row every time.
Here's a sample:
The third thing the
script would do is to have IMail deliver the message.
Here's
how to re-queue a single Q*.SMD + D*.SMD pair:
The short version being that if
you make sure that the Q*.SMD file (which can be any filename) contains
the "Q" row and a fully qualified D*.SMD file (which can be any
filename) you can just call:
smtp32.exe Qxxxxxxx.SMD and
IMail will queue it up immediately.
Ta-dah! Easy as world peace.
Andrew 8)
