Wayne Stallwood wrote:

Once you have collected a bit of information it is easy to filter the results down to SMTP traffic only, then filter out your exchange server.

In that case I'll give wireshark a go and if I have any trouble filtering the results sensibly I'll ask for some more advice when I reach that point.

Alternatively things like Netgear DG834's will log dropped packets if you banned SMTP out from anything other than the exchange server. That would quickly point to the culprit and unless there is any explicit reason why everyone needs SMTP outbound I would be tempted to leave that rule in place anyway.

A very good point, and a quick fix if the router is capable. I don't recall the brand but it's handling a 3-site VPN as well as road warriers so (a) its reasonably capable and (b) I'm not in a position to swap it out.

If you are wanting to do this on site then it really starts to depend on how things are set up there. Is it for example a typical SBS setup where the exchange server also happens to be the default gateway for the clients ?

SBS is not a gateway. The gateway is the router, which I am pretty sure has a built in switch (not hub) so I'd have to drop a hub in between the router and anything upstream to catch the traffic. Thanks for reminding me about that - I'd already thought about the traffic not being visible at a switch but had then gone on to think I could solve that by plugging a laptop directly into the router, forgetting that the router is just as much a switch as any of the others on the LAN.

On Fri, 28 Mar 2008 09:30:09 +0000 "Dennis Dryden" ddryden@gmail.com allegedly wrote:

I think you could get away with using something like ettercap(http://ettercap.sourceforge.net/) connected to the same switch to collect the traffic going to the gateway. It does some man in the middle sniffing so even in a switched environment you can see all traffic going to another host. Its been a while since i used it but if your prefer to look at the traffic in wireshark it spits out a file thats readable(at least i think it does).

Yep - ettercap reads and writes pcap files (as does tcpdump/ethereal/wireshark).

Mick

---------------------------------------------------------------------

This is a Microsoft free zone. Please do not send me Microsoft Word Documents. For some reasons, see:

http://www.gnu.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html ---------------------------------------------------------------------

* On Fri, 2008-04-04 at 08:24 +0100, Mark Rogers wrote:

Now that we have cleared the problem their IP address has been removed from the blacklists, although that's not a problem now as we configured their mail server (Exchange - horrible thing) to send via the ISP's smart host.

This got me thinking: Are there any voluntary blocklists where you can subscribe IPs that should never send any email, and so any email from that IP should be assumed to be spam?

I wouldn't do that

Some spam filters look through the session transcript and block a message if *any* IP address or host mentioned in it is blacklisted not just the last relay. So for example using this message as an example when it says

Received: from 87-127-158-124.no-dns-yet.enta.net ([87.127.158.124] helo=msl-office.co.uk

Even though you are using the.earth.li as a relay it will get blocked if 87.127.158.124 is blacklisted.

The best way is to lock down their gateway so only the Exchange box can send SMTP or if you want to go one step further lock it down so that only the exchange box can send smtp to only your relay server.

Wayne Stallwood wrote:

I wouldn't do that

Some spam filters look through the session transcript and block a message if *any* IP address or host mentioned in it is blacklisted not just the last relay.

Good point - Jonathan's point that trusting other IPs/hosts in the headers is unwise is also a good one, but I don't want to volunteer my email for capture by any mail server where the mail admin has decided to ignore that advice, so my plan falls over.

What I don't understand is why we don't yet have a simple validation capability within email. Eg: publish public key in DNS, sign email using private key, any email which is correctly signed you can be (almost) sure has come from the email client of someone allowed to send email from that domain.

It doesn't restrict the IP you can send from (no problem with roaming with laptop), it doesn't allow any trojan spamming from your machine (and therefore your IP) to be treated as legitimate, it should be fairly simple to add as a plugin for major email clients and mail servers.

I know that it doesn't confirm that the sender is someone you want to hear from, but surely it does confirm that the sender is who they say they are (that would make a large portion of the spam I get much easier to remove). It also means you could bounce spam back to sender (since you know it is their address you'e bouncing to).

What am I missing?

Jonathan McDowell wrote:

http://craphound.com/spamsolutions.txt

I'd be interested to know which of those rules you think my suggestion breaks?

Jonathan McDowell wrote:

Primarily you're proposing a technical solution which requires global buy in for it to be particularly useful.

I disagree. As long as it does not require changes to existing systems it has some (limited) use just between two parties. Agreed it becomes more useful when it scales up, though.

Your solution allows for the verification of a sender. It is useful for preventing people spoofing your address, but requires everyone to use it for verification in order to prevent you seeing blow back. It also doesn't let you be sure an email is verified rather than just from a domain without the verification support. And verifying senders won't actually cut out spam unless you only ever want to receive email from a whitelist of recipients.

I do agree with all of that.

At the outset I said that I understand that verification does not solve spam, but it is incredibly frustrating not having any general way of verifying an email is from who it says its from. Maybe I should just make more effort to understand GPG (I've never implemented it because I don't know anyone else who does that I routinely correspond with; a server-side solution I have more hope with).

While I do agree a standard way to verify email headers etc could be useful, I don't think it's going to kill spam.

I think it would make anti-spam measures a lot simpler if there was a general way of knowing who the email was from.

DKIM etc (which I wasn't aware of until this conversation) seem a lot better than SPF, because SPF was fundamentally unusable for most of the people I know (eg who need to send email from roaming laptops etc). Therefore at present, seeing valid SPF record is a good indicator of spam, as the spammers are the only ones using it. DKIM ought to be better. Big domains (eg aol.com, gmail.com, etc) seem to be the biggest problem (although if the domain owner authenticates the user before the mail goes through their server its not a problem for them to sign the email as it goes through).

On 04 Apr 14:12, MJ Ray wrote:

Mark Rogers mark@quarella.co.uk wrote:

...

What I don't understand is why we don't yet have a simple validation capability within email. Eg: publish public key in DNS, sign email using private key, any email which is correctly signed you can be (almost) sure has come from the email client of someone allowed to send email from that domain.

What I don't understand is why haven't you set this up using TXT records in your DNS and told us how to try it?

I think it may fail because of bandwidth and CPU costs (CPU on my mailservers is already pretty occupied by filtering out the obvious spam, even with very little reaching amavisd or spamd) but I'd be interested to know how it fares. It seems no worse than other shared whitelist schemes and makes sending more expensive for spammers too.

As I understand it, from what I read, this is nothing more or less than Yet Another implementation of DKIM[0].

Why not just use GPG extensively, make everyone sign their mail, and only accept mail that has a trust path to your key... that's almost as sane (and very obviously flawed).

Ho hum

On 04 Apr 19:30, MJ Ray wrote:

Brett Parker iDunno@sommitrealweird.co.uk wrote:

...

As I understand it, from what I read, this is nothing more or less than Yet Another implementation of DKIM[0].

Aren't Yahoo still claiming they have software patents on DomainKeys and threatening to drag any users to Californian courts?

Probably - as with SPF before it, it's not going to work long term... the correct solution (as it always has been) is to get rid of the complete muppets that send spam.

...

Why not just use GPG extensively, make everyone sign their mail, and only accept mail that has a trust path to your key... that's almost as sane (and very obviously flawed).

I thought we were discussing GPG here, but I see it wasn't explicit.

Indeed it wasn't, hence the pointer to DKIM, which (in my opinion) is also pointless. All of the various systems have the same fundamental flaw, there's no reason that spammers *couldn't* use them, and they're actually more *likely* to implement them to get over the various barriers in place.

*sigh*.

On 07 Apr 12:28, Mark Rogers wrote:

Brett Parker wrote:

...

Probably - as with SPF before it, it's not going to work long term... the correct solution (as it always has been) is to get rid of the complete muppets that send spam.

Many proposed anti-spam solutions fail on the "..but just because that's where it says the email is from doesn't mean that's where it was from" argument. Therefore a mechanism that allowed confidence in the sender details does have an anti-spam value (albeit not a simple "if it's there the message is OK").

Additionally, many people fall for phishing scams from natwest.com, hsbc.com, etc, and trojans sent from "trusted" domains like microsoft.com or symantec.com. Some key domains signing their emails would have a disproportionate benefit, imho. Yes I can think of many ways around this, but I don't buy the argument that we should stop chasing the spammers just because they'll keep running. I'm all for more "[getting] rid of the complete muppets that send spam" but no-one has come up with a good method for doing that as far as I can tell. For it to be a "solution" of any kind I think it needs a viable method to be presented, otherwise it's just an aspiration.

Continually trying to wrap technical solutions around social problems, unfortunately, does not work. Spam is a social problem. Re-educate (possibly with a 4x4) the spammers.

MJ Ray wrote:

What I don't understand is why haven't you set this up using TXT records in your DNS and told us how to try it?

It seems too simple...

Seriously, though, I looked at stuff like SPF and know its flaws. I just want a way that I (or anyone else) can send email, through normal SMTP, such that the recipient, should they choose, can verify that I sent it, regardless of whether they know who I am or have any previous relationship with me. Just that if it says it comes from example.com, then it did come from example.com.

Of-course if I didn't add the necessary signature in the header, or the necessary record in my DNS, then I would expect the recipient to treat it the way the do now. Normal email wouldn't be broken. (I'd suggest that the DNS should include flags to say whether all email from a domain must be expected to be signed or not, so that "reject if not signed" is an option.)

To be honest I assume there's either a similar scheme in operation I don't know about, or someone has thought about it and ruled it out.

I think it may fail because of bandwidth and CPU costs (CPU on my mailservers is already pretty occupied by filtering out the obvious spam, even with very little reaching amavisd or spamd) but I'd be interested to know how it fares. It seems no worse than other shared whitelist schemes and makes sending more expensive for spammers too.

There is a cost to the sender (miniscule except with bulk email). The cost to the recipient, if they choose to use it (and they can safely ignore it if they wish) is I think going to be less than the overhead of most existing spam checking.

Note that this does not try to be an anti-spam measure any more than SPF does. It would not stop the owner of i-send-spam.com sending mail from their domain, but it would stop them spoofing my address when they send it. Indeed it would be worth their while checking any domain they intend to use for spoofing to see if it has a published key, because spoofing a "reject-if-not-signed" domain would flag the sender up as spam. Hopefully this would mean my domain would get used much less for spoofing, and that would be an incentive for other people to sign their domains too. World domination would only be a step away!

Chris G wrote:

Isn't there an issue with what exactly "example.com" means? There would surely be issues with domains such as bt.com which probably have tens of thousands (if not hundreds of thousands) of users and probably no 'single source' such that mail from them could be signed consistently.

That would be a problem with things as I was looking at it, but could probably be worked around. I'm going off to look at DKIM now (thank's, Brett).

Come to that even one of my domains, isbd.net, resides on two totally separate (and separately administered) machines.

That shouldn't matter, provided you (as admin of isbd.net) know the private key for your domain.

On Fri, Apr 04, 2008 at 03:10:59PM +0100, Mark Rogers wrote:

MJ Ray wrote:

...

What I don't understand is why haven't you set this up using TXT records in your DNS and told us how to try it?

It seems too simple...

Seriously, though, I looked at stuff like SPF and know its flaws. I just want a way that I (or anyone else) can send email, through normal SMTP, such that the recipient, should they choose, can verify that I sent it, regardless of whether they know who I am or have any previous relationship with me. Just that if it says it comes from example.com, then it did come from example.com.

GPG allows you to do verification if that's what you want, but at the individual level. Just GPG sign all your outgoing mails. That or S/MIME are probably the most standard ways presently available for verifying mails.

J.