Jump to content

Email lists and confused parsing...


agsteele

Recommended Posts

I have identified an interesting quirk in the parser and wonder if anyone might have insight on overcoming the issue.

I am a member of an Email list (which happens to use the Mailman software).

I receive an Email which originates from an individual who is sending their Email through their own ISP's SMTP server. (In this case smtp3.wanadoo.co.uk [193.252.22.156]).

Now, 193.252.22.156 is currently listed in the SCBL so the mail item is correctly identified as originating from a potential source of spam and moved to one side for manual checking.

On parsing the Email I find that instead of identifying the source as 193.252.22.156, the parser, instead, wants to report the ip address of the mail list server [80.68.94.131] which appears later in the chain.

So the parser identifies based on one ip but reports a completely unrelated ip.

Tracking url: http://www.spamcop.net/sc?id=z1208775396za...f744a0d2a51cf1z

I'm wondering if this is an oddity that should not arise...

Logically, I'd want to see reports either for the originating ip alone OR for both the originating ip and the forwarding ip but I don't see the logic in identifying based on one ip and then reporting a separate ip.

As it happens, the Email is legitimate and the sender a victim of using the Wanadoo/Freeserve/Orange empire for his Email.

Andrew

Link to comment
Share on other sites

I am a member of an Email list (which happens to use the Mailman software).

I receive an Email which originates from an individual who is sending their Email through their own ISP's SMTP server. (In this case smtp3.wanadoo.co.uk [193.252.22.156]).

...

I'm wondering if this is an oddity that should not arise...

Logically, I'd want to see reports either for the originating ip alone OR for both the originating ip and the forwarding ip but I don't see the logic in identifying based on one ip and then reporting a separate ip.

No, the parser is doing as it is designed. The list is the source of the message to you.

On page http://www.spamcop.net/fom-serve/cache/14.html of Da Rulz On what type of email should I (not) use SpamCop?:

spam sent to mail lists/groups must not be reported using SpamCop except by the list owner. Subscribers may send a note to the list owner who can block the source from sending to the list or take responsibility for reporting the spam themselves.
Link to comment
Share on other sites

No, the parser is doing as it is designed. The list is the source of the message to you.

On page http://www.spamcop.net/fom-serve/cache/14.html of Da Rulz On what type of email should I (not) use SpamCop?:

I realise that this is the design, but it seemed illogical to trap a message based on the originating ip then to offer to report the unrelated list server ip.

I had a helpful note from Ellen suggesting a whitelist setting to avoid the problem hereafter...

Andrew

Link to comment
Share on other sites

I realise that this is the design, but it seemed illogical to trap a message based on the originating ip then to offer to report the unrelated list server ip.

Most servers do NOT trap on all IP addresses seen, only on the connecting address because that is the only address that is guaranteed not to be forged.

Spamcop's email service goes the extra mile to check all IP addresses, but then it is not generally rejecting messages but holding them, so it can process them a little longer. I can imagine some systems could easily become bogged down if they were to scan every IP address, especially if the spammer puts logs of bogus entries in there.

I though your complaint was about the parsing, not it getting trapped. I was explaining it should not have gotten to the parser because it should not have been submitted in the first place and monitoring the parse would indicate that the source was the list you subscribed to, giving you another opportunity to catch it and cancel. If it actually worked back to the source the list received it from, what would stop you from incorrectly reporting it any ways?

Link to comment
Share on other sites

If it actually worked back to the source the list received it from, what would stop you from incorrectly reporting it any ways?

You're absolutely correct.

I raised the question because with the large volume of spam mail that gets identified it is hard to be sure in the list of hundreds which ones have come from a list. So reaching the parser is quite common even if the offending item is not, then, submitted. Although I understand the logic, I am not sure it seems entirely logical to my mind :blink: But this would not be the first time I've been known to be confused by small things.

I suppose knowing how something works, even if I wouldn't make it work that way, does at least help me use the tool more effectively.

Andrew

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...