RE: [Declude.JunkMail] spf breaks email forwarding -

Tue, 07 Mar 2006 17:56:10 -0800

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 "S" sender row would normally be [EMAIL PROTECTED] but that violates SPF, so you instead specify [EMAIL PROTECTED] there.
 
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:
 
QC:\IMail\spool\tmp1B.tmp
Hmail.madriver.com
Ic507787800822fbd
WC:\IMail
S<[EMAIL PROTECTED]>
NRCPT TO:<[EMAIL PROTECTED]>
R<[EMAIL PROTECTED]>
 
 
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)
 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Hayer
Sent: Saturday, March 04, 2006 1:13 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] spf breaks email forwarding -

Matt wrote:
Real-world issues include working around bad implementation, such as surfglobal.net not configuring their server to reject messages that fail SPF.
SRS is a work around - and I'm simply asking if anyone has implemented it on an Imail/Declude platform. Kindly stay on topic....  I am aware of your feelings about SPF - all I'm doing is working out a solution with what is in place - an MTA bouncing my legit email.

I suggest you tell your customer that they can't forward their E-mail reliably unless surfglobal.net removes their SPF restrictions, and there is nothing that you can do about it.
Should I stamp my feet and make a face when I tell them that?  :)

I can simply ask SurfGlobal to accept me as a trusted sender - but I am trying to avoid that via SRS - so I will not have to make that call or any others.

-Nick

Reply via email to