[quote user="airyt"] We are getting lots of spam sent "from" ourselves. And no, we cannot filter on IP address since lots of outgoing mail comes from a variety of machines (hence the authentication).

[quote user="airyt"]

would like to stem the tide of spam that is coming in from external computers with the from being a local address.

 

Eg:

domain.com has an account info@domain.com

Mercury is configured to only allow authenticated users to send to external accounts. But of course, for email destined for local addresses, we don't force authentication.

Therefore, mail that has a (spoofed) FROM address (info@domain.com) with a TO of (info@domain.com) will not be forced to authenticate. Can we make this happen?

 We are getting lots of spam sent "from" ourselves. And no, we cannot filter on IP address since lots of outgoing mail comes from a variety of machines (hence the authentication).

Thanks, airyt

[/quote]

I've been seeing a massive increase in this type of spam lately too.

Thomas, why is it impossible to require clients to provide a password for sending?  The MercuryS module already provides password protected relaying controls, why can't the same mechanism be used to authenticate the client for non-relaying?

Thomas, why is it impossible to require clients to provide a password

for sending?  The MercuryS module already provides password protected

relaying controls, why can't the same mechanism be used to authenticate

the client for non-relaying?

[quote user="Thomas R. Stephenson"]It's not, you can require all client to authenticate for sending via MercuryS; [/quote]

That's all I need, but how do you enable it?  The connection controls in MercuryS only restrict relaying by password, I do not see any option to restrict all message sending.

[quote user="Barius"]

[quote user="Thomas R. Stephenson"]

It's not, you can require all client to authenticate for sending via MercuryS;

[/quote]

That's all I need, but how do you enable it?  The connection controls in MercuryS only restrict relaying by password, I do not see any option to restrict all message sending.

Huh?  Looks like we are not communicating.   If the mail client is not sending to a local address is relaying and authorization will be required to get through MercuryS.  Any mailer (or server) sending to a local user will always get through since you never require authentication any inbound mail.

I understand that the server cannot authenticate mail being delivered from non-local domains to the local domain, but why can it not authenticate mail that is addressed from it's own domain?  Any mail being sent from *@mydomain.com is always going to come from a client or server that is known to me, so why is it impossible to add a feature that would let me verify that fact via password?

If it is a protocol limitation I would understand, though it is my understanding that MIME is intended to be extensible...

I find that most of the spam with identical To/From headers is caught by the spamhaus.org blacklists, actually. Still, we are right now testing a daemon that will tag all incoming messages that have the same address as sender and recipient. (Using it to block messages would be possible as well, but then you would have to be sure that no local users send test messages to themselves or include their own address in mailings to recipient lists.)

/Rolf 

I understand that the server cannot authenticate mail being delivered from non-local domains to the local domain, but why can it not authenticate mail that is addressed from it's own domain?  Any mail being sent

from *@mydomain.com is always going to come from a client or server

that is known to me, so why is it impossible to add a feature that

would let me verify that fact via password?

The authentication is done by MercuryS and does not check any addresses at all.  The AUTH protocol is only triggered the sending system requests authorization using the AUTH command.  The protocol has nothing to do with the actual sending or receiving.  MercuryS can be set to block relaying and one of the ways to allow sending systems to relay is to allow systems that use the AUTH command to relay.  Servers sending to the system will ignore the AUTH statement in the receiving servers response since they are not trying to relay but deliver mail.

If it is a protocol limitation I would understand, though it is my understanding that MIME is intended to be extensible...

It has nothing to do with MIME since it's not even looking at the body of the mail message or the SMTP MAIL FROM: or RCPT TO: addresses. It's only looking at the AUTH command sent by the sending system.

[quote user="Rolf Lindby"]

I find that most of the spam with identical To/From headers is caught by the spamhaus.org blacklists, actually. Still, we are right now testing a daemon that will tag all incoming messages that have the same address as sender and recipient. (Using it to block messages would be possible as well, but then you would have to be sure that no local users send test messages to themselves or include their own address in mailings to recipient lists.)

/Rolf 

You should also mention that your daemon allows the addition of the X-RCPT-TO: header showing the original messages SMTP RCPT TO: address.  It might be that this would be more useful to most.  [:)]

[quote user="Thomas R. Stephenson"]It has nothing to do with MIME...[/quote]

Err, sorry, I meant SMTP not MIME.  I must have had a brain fart.

[quote user="Thomas R. Stephenson"]The authentication is done by MercuryS and does not check any addresses

at all.  The AUTH protocol is only triggered the sending system

requests authorization using the AUTH command.  The protocol has

nothing to do with the actual sending or receiving.  MercuryS can be

set to block relaying and one of the ways to allow sending systems to

relay is to allow systems that use the AUTH command to relay.  Servers

sending to the system will ignore the AUTH statement in the receiving

servers response since they are not trying to relay but deliver mail.[/quote]

I think that is my point, MercuryS should have a feature that would check not just the AUTH but also the MAIL FROM address.  Any time a mail is received with MAIL FROM <someuser>@<local-domain> it must be accompanied by a successful AUTH before it gets passed on for further processing.  Is there some technical limitation I'm not seeing here...?

[quote user="Rolf Lindby"]

I find that most of the spam with identical To/From headers is caught by the spamhaus.org blacklists, actually. Still, we are right now testing a daemon that will tag all incoming messages that have the same address as sender and recipient. (Using it to block messages would be possible as well, but then you would have to be sure that no local users send test messages to themselves or include their own address in mailings to recipient lists.)

/Rolf 

[/quote]

I find Spamcop.net is even better. Unfortunately, some of my clients have clueless IT depts. that don't know how to administrate their own Exchange servers and they keep getting blacklisted because they relay spam to the Spamcop honeypots.  It's forced me to turn off Spamcop entirely.  Strangely, Spamhaus doesn't seem to suffer from this problem, but it's also not as effective as Spamcop in my experience.

I think that is my point, MercuryS should have a feature that would check not just the AUTH but also

the MAIL FROM address.  Any time a mail is received with MAIL FROM

<someuser>@<local-domain> it must be accompanied by a

successful AUTH before it gets passed on for further processing.  Is

there some technical limitation I'm not seeing here...?

Probably could be coded but there are a couple that will reduce the usefulness.

1.  AUTH is ESMTP and any SMTP mailer (server or client) does not do AUTH.  Your road warriors may not have access to a mail client/server that does ESMTP AUTH.

2.  The MAIL FROM: address is not normally the same as the From: address in spam so it's pretty easy to send with the MAIL FROM: a faked domain with a From: address in the local domain.

That said Rolf Lindby's daemon does tag these messages with an X-BLOCKED header so that you can filter then off to the spam user.  You will still receive them but they will not get to the local users.

It's not clear from transflt.mer whether or not authenticated connections are checked.  If they aren't, and they shouldn't be if they are, then you're solution is to use that to simply deny mail sent from your domain.

Cheers,

Sabahattin

AFAIK the MAIL FROM transaction filters take no account of authentication, only the "exempt" setting from the MercS connection control list. (although a HELO rule can be deferred by using "D,.." instead of "H,..." to allow exemption by authentication)

Most of our clients are on the internal LAN or fixed external IP's, so these are exempted as above, and I have a couple of eXit rules in transflt.mer for the external dynamic usernames, before the Reject rule for MAIL FROM: *@ourdomain.

The few that get in via those usernames are all caught by Spamhalter.

This works ok for us at the moment, but I agree it would be good to see some more options to combat this type of spam.