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

Tue, 07 Mar 2006 20:08:03 -0800

Ok, I'll bite.

SRS is not part of SPF, it is just another protocol/method.  SPF has a problem in that it only suggests the "possibility" of forgeries, yet some have put in place strict rules that take this beyond the suggestion.  SRS is just one of several different proposed solutions for handling forwarded E-mail.  It has the most clout of all of them because it was also loosely defined by SPF's creator as being a solution to the forwarding problem in a paper on their site (if I recall correctly).  The bottom line here is that implementing SPF does not require implementing SRS.  Their strategy for combining these things (and others), is far from clear at this time.

Back to SRS.  SRS isn't just simply changing the Mail From address, it is a system that requires both the encoding and parsing of the Mail >From addresses, and it requires both the sending and receiving MTA to be SRS aware.  The following is from what is apparently the master SRS document located at http://www.libsrs2.org/srs/srs.pdf :
The SRS scheme must ensure that it is not possible to construct an SRS address which forwards mail to an arbitrary user. This is achieved by introducing a cryptographic element into addresses such that it is possible to spot tampering with the destination user or host fields. The actual SRS address format looks like this:

[EMAIL PROTECTED]

The fields are as follows:
  • SRS0: This identities the address as an SRS address. This allows hosts to distinguish easily between ordinary email addresses and SRS return addresses directed to the same mail server. The 0 is in some sense a version number for the protocol; it is used later.
  • HHH: This is a cryptographic hash of the fields timestamp, hostname and local-part. This hash may only be generated or validated by someone in possession of the secret key used in the cipher, that is to say, forward.com. If a spammer tries to forge an SRS address, he will not be able to generate a valid hash, and forward.com will simply reject the mail.
  • TT: This limits the validity of an SRS address. It is expected that bounces will return within a few days, at most a month, of an email being sent. If a spammer gets hold of an SRS address for a user, then they can use the SRS system to bounce mails to that user. The limited validity of the timestamp reduces considerably the value to the spammer of the SRS system, since none of his target addresses is valid for more than a few days. The spammer cannot falsify the timestamp in an SRS address because this would cause a failure of the cryptographic check on the forwarder.
  • Hostname: The hostname of the original sender and final recipient for bounces.
  • local-part: The local-part of the original sender and final recipient for bounces. The order of the
  • hostname and local-part was chosen to allow the use of the = character as a separator.
There is also an SRS1 format in addition to the SRS0 format above.  SRS1 is for forwarding things that have already been forwarded by SRS.  It's in the paper.

One big caveat that the paper notes is the violation of RFC's 2821 and 2822 where there is a 64 character limit to the user address, and this limit is enforced by MailGuard and Cisco PIX, and I would imagine other MTA's.  SRS "adds 21 characters plus two local hostnames as overhead to the local part" the paper explains.  Maybe they should rewrite RFC 2811 and 2822 before releasing this?

Another caveat is that hosts or admins that aren't SRS aware may improperly identify the forwarder's domain as being the source of spam.

Another big issue is that SPF does not specify the mechanism for validating forwarding, and there are 4 other competing solutions that are summarized (not fully) on the following page:

    http://www.michaelbrumm.com/spf-forwarding.html

The recommended forwarding mechanism for the proposed marrying of SPF and Caller ID is to add the "SUBMITTER" parameter to ESMTP.  Even the SPF page on SRS mentions this as an alternative/replacement.  None of this information seems to have been updated since somewhere in 2004.

Note to Sandy: I think that Declude locks the Q* file, and if so, writing a Declude plug-in won't work.  Besides that, it would only be a partial implementation of true SRS since the MTA needs to be aware in order to prevent forgeries.

Matt




Colbeck, Andrew wrote:
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