Suggestion for SPF Compatible Tagging...
Adding a "Received field" in the filter rules would allow easy tagging of the "envelop-from" inclusion for better tagging of spammers.

Right now I cannot effectively tag Based on envelop-from because it cannot be isolated in the "Received" field. With isolation there would be very specific (and I think powerful) control added to MWP for tagging spammers.

I have had to deal with a lot of spoofing, and spf is becoming my friend. If it also becomes MWP's friend... well I think this is a much needed addition.

What do you all think?
Cheers,
TwoHawks

How would the from address in any form help? 90% plus of my incoming spam has that forged and it changes with every spam run.

Hi Stan_q, thanks for resonding...
I am not talking about the "From" field, and yes, "everyone knows" that is easily and commonly forged.
I am talking about the "Received" field(s) and their "tags".

Although I am sure any field may be able to somehow be forged, typically the "Received" and "Return-Path" fields are generated by the sending server. Just as spf does reverse lookup with these, one of the values that is worth [mwp] checking is either and/or both the "from" and "envelop-from" tags (not fields) appearing within the Received field(s) ...and checking these in various ways against the Return-Path field, and possibly other fields if you are having a server issue forms and things for you.

--You can build filters to flag spoofed email, that I have found very reliable myself anyway, but it is difficult to nail it down easily without having access to the "Received" field(s) as one of the filter rule selections.

One way this could be very helpful to administrators is when we have numerous web accounts we are managing with form mail. The server gateways handling email always set these flags in the received field, and you can reliably run comparisons using mwp filters to weed out the real stuff from the spammers.

I just got majorly 'owned' by some spoof scenario, and so I have been on the rebound making lots of changes on my servers, and in my mwp monitoring on my monitoring pc.
Although I am sure there's just about nothing you cannot do with regx, I would definitely have a lot less work, and more flexibility, if the Received field were included in the filter selection. I would be able to selectively weigh in on what servers are presumably sending, and for whom, while authenticating against the Return-path(s), and with a lot less hassle.

Hope this makes sense.
Cheers,
TwoHawks

In fact the Received fields are typically spoofed. However the last few aren't (since they are placed there by legit mail servers). Each added Received field should link to the previous one so reverse lookup should spot the discontinuity and thus the spoof. .... Or of course the actual source if not spoofed.

I expect there are some problems, the first being that spammers now use zombied computers so it's easy for spammers to keep changing the source. Also doing such reverse lookups adds additional delays and computation times. As well, many email services fail to pass on those fields. That said, I certainly agree that the Received fields offers the most fruitful spam clues so I would seriously consider any product that makes use of those fields.

Thanks for your reflections and insights, Ikeb.

Yes, I have not yet investigated enough to be observing how Received-from header section info is spoofed, but certainly
- considering the attention it is getting nowadays, with spf becoming accepted and implemented more and more,
- and also considering that if its valid in a product such as MWP to be reviewing header info in a segmented fashion (isolating common fields for review),
- and it is not ignoring providing us the ability to isolate sections that may be spoofed, such as the from field...
...then why wouldn't it also provide segmented access the the other fields, such as received-from, and possibly others, such as common x-headers even, etc?

So it would seem that just because a field may be spoofed obviously doesn't make it un-valuable to be isolating for review. As well, to mention again, I can instruct my mail server to use the Received-from field in specific ways - just as uch as any spoofer might do, and then it can be very valuable for clients to be able to inspect (for) that info, and correlate it with other info, in their email headers for better filtering.

Cheers,
TwoHawks

You should have no problem isolating anything in the header for your own use using regex filters to identify the line you are interested in and the data that you want to filter against.

I have a couple X-Header filters set to scan the entire header and look for the X line identifier followed by the data I'm interested in. Works fine for me. Can't see why that wouldn't work for you on other lines.

Give it a try and if you find something that works give the details so others can try it and if it becomes popular it has a much better chance of getting added to MW.

Okay Stan.
I mean, its not as if I don't realize what you are suggesting, and I will be looking into doing this, its just that ...the problem to tackle is there are usually several Received-from fields, not only one. This makes things more challenging...

...so I guess I will have to write a test expression that very roughly looks for, say for instance, an occurance of something like:
"Received-from: .* envelop from .* some-email-address-or-whatever .* end-of line"

...assuming that Received-from field doesn't generate a new line break if it ends up naturally wrapping.

Sometime this week I can sit down with this. I will post anything fruitful here.

Cheers,
HTH

As a MW user I've found your best bet is to find something that works now and live with it rather than waiting for your suggested feature to make it into MW. Look back at all the good suggestions in this forum that have not made the cut after several versions...