Missing TLD |
Post Reply |
Author | |
StevenJohns
Senior Member Joined: 03 August 2006 Status: Offline Points: 119 |
Post Options
Thanks(0)
Posted: 09 November 2007 at 6:46pm |
Roberto,
I am running SF 3.5.4.718 and have noticed the following in the logs.
11/09/07 16:26:35:468 -- (8632) Connection from: 213.189.178.213 - Originating country : Belgium
11/09/07 16:26:35:984 -- (8632) Received MAIL FROM: <linkage@norika-fujiwara.com > 11/09/07 16:26:36:093 -- (8632) Received RCPT TO: mark@quantumwarrior.co.uk 11/09/07 16:26:36:390 -- (8632) - Invalid MX record - DNS Server Reports Query Server Error 11/09/07 16:26:36:390 -- (8632) Resolving 213.189.178.213 - host-213-189-178-213.brutele.be 11/09/07 16:26:36:390 -- (8632) 213.189.178.213 - Mail from: linkage@norika-fujiwara. To: mark@quantumwarrior.co.uk will be spam-tagged 11/09/07 16:26:36:890 -- (8632) Starting queueing procedures 11/09/07 16:26:36:906 -- (8632) EMail from linkage@norika-fujiwara. to mark@quantumwarrior.co.uk was queued. Size: 1 KB, 1024 bytes 11/09/07 16:26:36:906 -- (8228) Sending email from linkage@norika-fujiwara. to mark@quantumwarrior.co.uk -- 11/09/07 16:26:36:906 -- (8632) Starting bayesian procedures 11/09/07 16:26:36:937 -- (5080) Time to add Msg to Bayes corpus:16 11/09/07 16:26:37:062 -- (8632) Blacklist cache - Added 213.189.178.213 to limbo 11/09/07 16:26:37:202 -- (8228) EMail from linkage@norika-fujiwara. to mark@quantumwarrior.co.uk -- was forwarded to 127.0.0.1:999 11/09/07 16:26:37:312 -- (8632) SFDB - Added 213.189.178.213 - Response: Error=0 11/09/07 16:26:37:312 -- (8632) Disconnect As you can see, an email from linkage@norika-fujiwara.com arrives, gets spam tagged correctly and then forwarded to my internal email server for futher processing. However, when it forwards the email, it is missing the .com from the domain name.
I have checked the logs on the internal email server and they confirm that the .com is missing.
I have noticed that there is a space after the .com and before the > on the incomming email, has this got anything to do with it??
Cheers
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
We were able to duplicate this behavior, and yes, it is caused by the space before the closing bracket. We're still going thru the RFC, but so far at first sight it seems that spaces are not allowed between the brackets "<" and ">". If this is confirmed, we are hesitant to modify SpamFilter to accommodate for this scenario, as we're concerned in potentially introducing unwanted bugs in the address verification process.
|
|
StevenJohns
Senior Member Joined: 03 August 2006 Status: Offline Points: 119 |
Post Options
Thanks(0)
|
My understanding of the RFC is that spaces are not allowed as you correctly pointed out.
>>> we are hesitant to modify SpamFilter to accommodate for this scenario, as we're concerned in potentially introducing unwanted bugs in the address verification process.
This is obviously already a bug in your address verification process as SF hasn't just dropped the space, its also dropped the com off the end. Look at the incomming email addresss, it is correct (albiet with a trailing space) but you are chopping off legitimate charicters.....what is your explanation for this??
I can't understand how you can
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
When feeding non-RFC compliant data, there is no rule on how to behave... so "unexpected" behavior will occur. In this specific case, SpamFilter drops the space and the last suffix in the domain. This is because spaces are used as delimiters in the MAIL FROM command, and if the space appears where it's not supposed to be, strings will be truncated where they otherwise should not be.
|
|
StevenJohns
Senior Member Joined: 03 August 2006 Status: Offline Points: 119 |
Post Options
Thanks(0)
|
err, still don't understand why you drop the last suffix??? seems like a very strange thing to do.
|
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
It's not strange at all. There are RFC rules that define where spaces should be. Dots, "@", spaces, and other characters MUST be placed in a certain way. Text is extracted by code that is built to behave as the RC dictates. If one of these characters is out of place, the code will simply not know, and will continue to extract text following the same rules. It will of course extract incorrect text, with completely unpredictable results. We don't "drop the last suffix"... it's the text parsing routines that were made to behave in a certain way that are "thrown off" due to the incorrect placement of one of the separation characters.
We really recommend you contact the sender (or the administrators of the sender's domain) to inform them on the non-compliance issue. |
|
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.285 seconds.