Messages quarantined using ’Return-Path’? |
Post Reply 
|
| Author | |
TommyBoy 
Newbie 
Joined: 11 May 2006 Location: United States Status: Offline Points: 5 |
 Post Options
 Thanks(0)
 Quote Reply
 Topic: Messages quarantined using ’Return-Path’?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 j.s@mydomain.com and m.s@mydomain.com were expecting mail from 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: SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net -- not the Mail-From address of l.r@lusix.com. Each user then unquarantined the e-mail, expecting that l.r@lusix.com is now whitelisted... unfortunately it has only whitelisted the goofy address from the 'Return-Path' (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 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 ------_=_NextPart_001_01C68441.623006C5 ------_=_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 |
|
 |
|
|
LogSat
Admin Group 
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
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> |
|
|
|
|
TommyBoy
Newbie
Joined: 11 May 2006 Location: United States Status: Offline Points: 5 |
Post Options
Thanks(0)
Quote Reply
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: SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net To: 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 l.r@lusix.com. Both the mail from and the SpamFilter X-SF-Return-Path show 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
|
|
|
|
|
LogSat
Admin Group
Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
Quote Reply
Posted: 03 June 2006 at 12:13am |
|
TommyBoy,
We're scratching our heads too... the "SRS0=KeQV=7S=lusix.com=l.r@srs.perfora.net" address doesn't appear anywhere in the original headers (before being processed by the other servers). But somehow it ends up the logs (and in the Return-Path headers added by other servers). This would indeed indicate that the original "MAIL FROM" command did contain it. However SpamFilter's 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. |
|
|
|
|
Desperado
Senior Member 
Joined: 27 January 2005 Location: United States Status: Offline Points: 1143 |
Post Options
Thanks(0)
Quote Reply
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 |
|
|
The Desperado
Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
|
|
|
|
TommyBoy
Newbie
Joined: 11 May 2006 Location: United States Status: Offline Points: 5 |
Post Options
Thanks(0)
Quote Reply
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. 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 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 (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 (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 (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?
|
|
|
|
|
TommyBoy
Newbie
Joined: 11 May 2006 Location: United States Status: Offline Points: 5 |
Post Options
Thanks(0)
Quote Reply
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)...
|
|
|
|
Topic Options|
Post Reply
|
|
Tweet
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.219 seconds.