Print Page | Close Window

Messages quarantined using ’Return-Path’?

Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=5634
Printed Date: 21 January 2025 at 2:35am


Topic: Messages quarantined using ’Return-Path’?
Posted By: TommyBoy
Subject: Messages quarantined using ’Return-Path’?
Date Posted: 01 June 2006 at 6:54pm

Running v3.0.1.561, we are seeing instances of incoming messages being quarantined using the 'Return-Path' address in the message header.  In a specific case, the incoming e-mail was quarantined because it was in the SFDB.

Unfortunately, users are complaining because when they use the web interface to unquarantine/forward their mail (and subsequently autowhitelist the e-mail address), it is using the whitelisted 'mauled' e-mail address in the 'Return-Path' instead of the normal 'Mail-From' address.

An example Internet Header taken from outlook is listed below.  Our users mailto:j.s@mydomain.com - j.s@mydomain.com and mailto:m.s@mydomain.com - m.s@mydomain.com were expecting mail from mailto:l.r@lusix.com - l.r@lusix.com .  The message was quarantined due to a SFDB hit.  When it was quarantined, it was logged to the quarantine database using the 'Return-Path' address: mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net  -- not the Mail-From address of  mailto:l.r@lusix.com - l.r@lusix.com .

Each user then unquarantined the e-mail, expecting that mailto:l.r@lusix.com - l.r@lusix.com is now whitelisted... unfortunately it has only whitelisted the goofy address from the 'Return-Path' ( mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net ).  Worse, this goofy 'Return-Path' address changes with each new e-mail message from this sender -- so  mailto:l.r@lusix.com - l.r@lusix.com is quarantined (because of the mauled value in the 'Return-Path') with each subsequent e-mail.

The users are complaining that they have received e-mail from this domain for two years without a problem.  I'm wondering if this is a new symptom with SFDB functionality.

Internet Header From Outlook:

Microsoft Mail Internet Headers Version 2.0
Received: from gateway.mydomain.com ([10.1.2.6]) by backend.mydomain.com with Microsoft SMTPSVC(6.0.3790.211);
  Wed, 31 May 2006 07:32:30 -0700
Received: from spamfilter ([10.1.3.8]) by gateway.mydomain.com with Microsoft SMTPSVC(6.0.3790.211);
  Wed, 31 May 2006 07:32:30 -0700
Received: from 217.160.230.40 by spamfilter.mydomain.com (LogSat Software SMTP Server) Tue, 30 May 2006 16:33:11 -0700
Received: from [172.23.129.4] (helo=NTXBEUS01.exchange.xchg)
 by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis),
 id 0MKp2t-1FlDi02Fxo-00020c; Tue, 30 May 2006 19:33:10 -0400
Received: from ntxbeus06.exchange.xchg ([172.23.126.7]) by NTXBEUS01.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830);
  Tue, 30 May 2006 19:32:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----_=_NextPart_001_01C68441.623006C5"
Subject: FW: Meetings Next Week
Date: Tue, 30 May 2006 19:32:56 -0400
Message-ID: < mailto:318B38FE80ACE64FBE4A1AF84F70E53C1DE8BF@ntxbeus06.exchange.xchg - >
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Meetings Next Week
Thread-Index: AcaACc+gUK/b4LWTTgql4ri8A1MpuwACGk0AAQJThUAACXKYcA==
From: "l r" < mailto:l.r@lusix.com - >
To: "S, J" < mailto:JS@mydomain.com - >,
 "S, M" < mailto:MS@mydomain.com - >
X-OriginalArrivalTime: 30 May 2006 23:32:58.0364 (UTC) FILETIME=[624DBBC0:01C68441]
X-Server: LogSat Software SMTP Server
X-SF-RX-Return-Path: mailto:l.r@lusix.com - X-SF-HELO-Domain: mout.perfora.net
Return-Path: mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net

------_=_NextPart_001_01C68441.623006C5
Content-Type: text/plain;
 charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

------_=_NextPart_001_01C68441.623006C5
Content-Type: text/html;
 charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


------_=_NextPart_001_01C68441.623006C5--

SpamFilter Log Snippet

05/30/06 08:49:17:935 -- (85604) Connection from: 217.160.230.40  -  Originating country : United States
05/30/06 08:49:18:575 -- (85604) Resolving 217.160.230.40 - mout.perfora.net
05/30/06 08:49:23:716 -- (85604) - SFDB filter match - relevance:4
05/30/06 08:49:23:716 -- (85604) 217.160.230.40 - Mail from: mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - To: mailto:m.s@mydomain.com - will be rejected
05/30/06 08:49:24:169 -- (85604) EMail from mailto:SRS0=KeQV=7S=lusix.com=l.rl@srs.perfora.net - to mailto:m.s@mydomain.com - was received and quarantined. Size: 1 KB, 1024 bytes
05/30/06 08:49:24:372 -- (85604) Blacklist cache - Added 217.160.230.40 to limbo
05/30/06 08:49:24:372 -- (85604) Disconnect


Replies:
Posted By: LogSat
Date Posted: 01 June 2006 at 8:28pm
SpamFilter should only use the email address specified in the MAIL FROM smtp command when processing emails (and usually ends up being listed in the "Return-Path" header). That MAIL FROM address is added by SpamFilter to the "X-SF-RX-Return-Path" header, and usually will match the "Return-Path" header. SpamFilter ignores the "Mail From" header as it is usually fake. This is by design, and will probably not change.

The entries in your logs however do not seem correct. The email as received by SpamFilter is time-stamped 16:33:11:

Received: from 217.160.230.40 by spamfilter.mydomain.com (LogSat Software SMTP Server) Tue, 30 May 2006 16:33:11 -0700

However in the activity logfile, the time stamp is around 08:39:23. This would indicate that the headers reported are not the ones for the email in the log.

I say this because in the email headers I see:

X-SF-RX-Return-Path: l.r@lusix.com

This is the MAIL FROM address that SpamFilter uses to add to the log, and adds to the database. So in this case, the address you would have liked to see output in the quarantine "From" field is actually the one that should be there. However, this email does not seem to be the one in the logs, as the entry "SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net" is not used by SpamFilter, and in fact does not appear anywhere in the headers when it reaches SpamFilter.

Please note that the "Return-Path" email address header is usually added by every SMTP server that "touches" the email. SpamFilter does indeed add the "Return-Path" headers, and the one SpamFilter added is *not* the one you highlighted in red. The one SpamFilter added is reported by the header:

X-SF-RX-Return-Path: l.r@lusix.com

... we added that headr to indicate which "Return-Path" we added, knowing that other servers after SpamFilter will modify such header. So we know for certain what we added.. and if that's different from the "Return-Path" in the final email, we know for sure another server has modified it. In your case, judging from the headers there are at least two more SMTP servers that handled the email after SpamFilter, so one of them is the one that modified the email.

..but again, according to the headers, this one particular email should have "l.r@lusix.com" in the "From" database field. Also, it's to note that the original "Return-Path" that we added had the address "l.r@lusix.com", which in this case, matches the address specified in the "From" email header:

From: "l r" <l.r@lusix.com>




-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP

Posted By: TommyBoy
Date Posted: 02 June 2006 at 1:47pm

Sorry... the log snippet I included was from a transaction earlier in the day (and, I did modify e-mail addresses to protect the innocent).  Below is the correct log snippet for the transaction.  You will see the same behavior.

What has me scratching my head is the  log entry "Mail from: mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - To: mailto:j.s@mydoman.com - will be rejected".  How is SpamFilter getting this as the source e-mail address?  I can query the SpamFilter quarantine table directly and see this is indeed what is inserted into the quarantine table instead of mailto:l.r@lusix.com - .  Both the mail from and the SpamFilter X-SF-Return-Path show mailto:l.r@lusix.com - l.r@lusix.com -- why then is this goofy address used to quarantine the mail?

I have enabled the Debug Monitor for the source IP address to see if I can get more info.

05/30/06 16:33:09:533 -- (85520) Resolving 217.160.230.40 - mout.perfora.net
05/30/06 16:33:10:080 -- (85520) - SFDB filter match - relevance:6
05/30/06 16:33:10:080 -- (85520) 217.160.230.40 - Mail from: mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - To: mailto:j.s@mydoman.com - will be rejected
05/30/06 16:33:11:049 -- (85520) - SFDB filter match - relevance:6
05/30/06 16:33:11:049 -- (85520) 217.160.230.40 - Mail from: mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - To: mailto:m.s@mydoman.com - will be rejected
05/30/06 16:33:12:002 -- (85520) EMail from mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - to mailto:j.s@mydoman.com - , mailto:m.s@mydoman.com - was received and quarantined. Size: 6 KB, 6144 bytes
05/30/06 16:33:12:205 -- (85520) Blacklist cache - Added 217.160.230.40 to limbo
05/30/06 16:33:12:205 -- (85520) Disconnect

 

Posted By: LogSat
Date Posted: 03 June 2006 at 12:13am
TommyBoy,

We're scratching our heads too... the " mailto:SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net - X-SF-Return-Path, which is supposed to indicate the contents of that MAIL FROM command, does not show it.

We've been trying, unsuccessfully, to replicate this. On the other hand, we didd indeed find a logging bug doing this, but it deals with the from address diplayed when logging "Sending email from nnnn to mmm" events. These ones do show the address in the "From" header, rather than the MAIL FROM ones. This is a logging issue, and we'll take care of it, but is not related to what we're seing here.

If you can capture the headers with either SpamFilter's debug feature, or with Ethereal or Microsoft's Network Monitor, we'll be glad to take a look, as it is very possible there may be a bug under specific circumstances, which we're currently not able to replicate.

-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP

Posted By: Desperado
Date Posted: 03 June 2006 at 10:45pm

Roberto,

perfora.net does email forwarding and we have many customers that use it and it causes us MANY problens.  As a result, we have
mailto:*@srs.perfora.net - *@srs.perfora.net
in our allowed from list.



-------------
The Desperado
Dan Seligmann.
Work: http://www.mags.net
Personal: http://www.desperado.com

Posted By: TommyBoy
Date Posted: 05 June 2006 at 7:00pm

The goofy address appears to be the result of the Sender Rewriting Scheme (SRS). See http://www.openspf.org/srs.html - http://www.openspf.org/srs.html .  Seems that SRS was specifically intended to allow forwarding services to pass SPF checks when forwarding items with other domain names.

In this case, perfora.net is a mail forwarder as Dan had mentioned (for the 1and1.com hosting service) that is being used by lusix.com.  It appears that at the time these messages were quarantined, the perfora.net outboud mail server (mout.perform.net @ 217.160.230.40) was being blacklisted in the SFDB.  That's why the messages were quarantined.  The gotcha is that SRS does maul the MAIL FROM address as seen in the debug:

>>EHLO mout.perfora.net
<<250-8BITMIME
<<250 HELP
>>MAIL FROM:< mailto:SRS0=O6RP=7X=lusix.com=l.r@srs.perfora.net - SRS0=O6RP=7X=lusix.com=l.r@srs.perfora.net >
<<250  Address Okay
>>RCPT TO:< mailto:C.H@mydomain.com - C.H@mydomain.com >
<<250 mailto:C.H@mydomain.com - C.H@mydomain.com Address Okay
>>DATA
<<354 Start mail input; end with <CRLF>.<CRLF>
>>Received: from [172.23.129.4] (helo=NTXBEUS01.exchange.xchg)
>>atchers, and think that sheet
>>n=20
>>rset=3Dus-ascii">
>></FONT></SPAN>&nbsp;</DIV>
>>
>>/SPAN> =
>>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D343001401-03062006><FONT =
>>C =
<<250 Ok
>>QUIT
<<221 Signing Off

So maybe the real issue is not necessarily the incoming goofy e-mail address, it's the fact that perfora.net is popping into and out of the SFDB blacklist.  And since SRS 'mauls' the e-mail address with hashes and other stuff, the e-mail address is quarantined using the ever-changing SRS 'rewritten' version of the e-mail address. 

Then when the user releases the item from quarantine, they think they've unquarantined all items from that person ( mailto:l.r@lusix.com - l.r@lusix.com ) for good (via whitelisting) so that even if subsequent e-mail items from that address fail blacklisting, the mail would pass. 

Unfortunately, the user only ends up whitelisting the goofy hashed e-mail address ( mailto:SRS0=O6RP=7X=lusix.com=l.r@srs.perfora.net - SRS0=O6RP=7X=lusix.com=l.r@srs.perfora.net ) -- and the next incoming SFDB blacklisted e-mail address gets quarantined, too.  Worse, for some reason the unquarantined mail appears in Outlook as coming from the original e-mail address ( mailto:l.r@lusix.com - l.r@lusix.com ), futher confusing the end user.

Obviously, SpamFilter obtains the original e-mail address though some data element in the SMTP transaction (X-SF-RX-Return-Path).  Is it possible to have SpamFilter check this value against the whitelist as well prior to quarantining/rejecting an item?

 

Posted By: TommyBoy
Date Posted: 09 June 2006 at 1:33pm

We ended up adding to the whitelist with "*lusix.com*" -- which appears in the SRS mauled address.  There were a few other SRS formatted messages that we found domains we could whitelist as well.  This allowed us to pass the e-mail without opening up the whole perfora.net domain.  It also allowed us to clean up a significant number of SRS entries in the whitelist text file that users' had released quarantined mail from.

Still would be kind of cool to somehow test for the acceptability of an e-mail from a domain originating behind a mail forwarder (i.e. lusix.com) instead of only the mail forwarders domain (perfora.net)...

 


Print Page | Close Window