Spam attacks

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Spam attacks

Dave Johnson-2
Hi all

Is there anyway of stopping the from [hidden email] to "[hidden email]" spam attacks?

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
W dniu 2009-03-03 08:25, Dave Johnson pisze:
Hi all

Is there anyway of stopping the from [hidden email] to [hidden email] spam attacks?


Hi

Without knowing your config it's hard to say what are you already doing.
Are you using SASL authentication? If not, have a look here: http://www.postfix.org/SASL_README.html#server_sasl
To get really useful help (not just speculations) you have to read http://www.postfix.org/DEBUG_README.html#mail 

Pawel Lesniak



Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Noel Jones-2
In reply to this post by Dave Johnson-2
Dave Johnson wrote:
> Hi all
>
> Is there anyway of stopping the from "[hidden email]"
> <mailto:[hidden email]> to "[hidden email]" spam attacks?
>
> Regards
>

If you're not using zen.spamhaus.org already, you should
start.  If your site is too large to qualify for their free
use, the paid feed is well worth it.

You can use a policy server that rejects mail when the sender
and recipient are the same.  It's reported that postfwd can do
this, probably others too.
http://www.postfix.org/addon.html#policy

Some people reject their own domain from outside,
unauthenticated clients, but this will certainly reject some
amount of legit mail.

   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
W dniu 2009-03-03 17:46, Noel Jones pisze:
> Some people reject their own domain from outside, unauthenticated
> clients, but this will certainly reject some amount of legit mail.

Could you write a little bit how is it possible to reject legit mail by
rejecting unauthenticated clients when all users do use SASL
authentication or are in my_networks?


Pawel Lesniak


Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Gerardo Herzig
In reply to this post by Dave Johnson-2
Dave Johnson wrote:
> Hi all
>
> Is there anyway of stopping the from "[hidden email]" to "[hidden email]" spam
> attacks?
>
> Regards
>
>  
>
Well. If you are delivering via procmail, you can have a procmail rule
like this one (untested, and posibly larger than a experienced procmail
user will do, but should work):

SHELL=/bin/bash
__TO=`formail -z -x 'To:'`
__FROM=`formail -z -x 'From:'`

:0fw
* __TO ?? __FROM
| formail -I "X-From-And-To-Are-The-Same: Yes"

## This will forward the mail, with a X-header that you can chase via a
spamassasin rule. I will prefer this way instead of just droping the
mail, cause, as many has told you, will probably block legitimate mail.

HTH
Gerardo
Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Gerardo Herzig
In reply to this post by Paweł Leśniak
Paweł Leśniak wrote:

> W dniu 2009-03-03 17:46, Noel Jones pisze:
>> Some people reject their own domain from outside, unauthenticated
>> clients, but this will certainly reject some amount of legit mail.
>
> Could you write a little bit how is it possible to reject legit mail by
> rejecting unauthenticated clients when all users do use SASL
> authentication or are in my_networks?
>
>
> Pawel Lesniak
>
>
>
Well, some ppl can configure to use their @myhost email, via, lets say
@yahoo smtp. This is a legit mail that will be rejected.


Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Noel Jones-2
In reply to this post by Paweł Leśniak
Paweł Leśniak wrote:

> W dniu 2009-03-03 17:46, Noel Jones pisze:
>> Some people reject their own domain from outside, unauthenticated
>> clients, but this will certainly reject some amount of legit mail.
>
> Could you write a little bit how is it possible to reject legit mail by
> rejecting unauthenticated clients when all users do use SASL
> authentication or are in my_networks?
>
>
> Pawel Lesniak
>
>

Some legit "reminder" type services, some meeting
notifications, and other legit mail might arrive with you as
the sender.  Maybe not best practices, but it's legit mail and
such a policy will reject it.

You can send yourself mail via eg. gmail or your home ISP with
your postfix domain as sender address.  Some people really do
this.

The "some amount" of legit mail you will reject is highly
dependent on your users. Some sites will see quite a bit,
others very little.  Some people consider this a horrible
idea, others a useful policy with an acceptable risk.  You get
to pick which side of the fence you live on.


   -- Noel Jones

Reply | Threaded
Open this post in threaded view
|

RE: Spam attacks

MacShane, Tracy
In reply to this post by Paweł Leśniak
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Pawel Lesniak
> Sent: Wednesday, 4 March 2009 4:19 AM
> To: postfix users list
> Subject: Re: Spam attacks
>
> W dniu 2009-03-03 17:46, Noel Jones pisze:
> > Some people reject their own domain from outside, unauthenticated
> > clients, but this will certainly reject some amount of legit mail.
>
> Could you write a little bit how is it possible to reject
> legit mail by rejecting unauthenticated clients when all
> users do use SASL authentication or are in my_networks?
>
>
> Pawel Lesniak
>
>

We have a very clear policy that users are only permitted to relay mail
from our networks. If they are sending from home, they use webmail.
We've had one or two instances where external organisations have used
some kind of auto-reply mechanism which purports to send from our users,
but we simply tell them to fix the sender address. We use a sender
access map to reject the spurious senders that aren't coming from
my_networks. You can use warn_if_reject to test the impact of this
measure for a few days or weeks.

main.cf
======
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_non_fqdn_sender,
  check_sender_access hash:/etc/postfix/sender_access


# cat /etc/postfix/sender_access
ourdomain.com         REJECT
ourdomain.gov.au          REJECT
Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
W dniu 2009-03-03 23:34, MacShane, Tracy pisze:

We have a very clear policy that users are only permitted to relay mail
from our networks. If they are sending from home, they use webmail.
We've had one or two instances where external organisations have used
some kind of auto-reply mechanism which purports to send from our users,
but we simply tell them to fix the sender address. We use a sender
access map to reject the spurious senders that aren't coming from
my_networks. You can use warn_if_reject to test the impact of this
measure for a few days or weeks.

main.cf
======
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_non_fqdn_sender,
  check_sender_access hash:/etc/postfix/sender_access


# cat /etc/postfix/sender_access
ourdomain.com        	REJECT
ourdomain.gov.au          REJECT
  
So you too advocate (if I clearly understand you) my point of view, where those "legit mails", which Noel was talking about,
are just misconfigurations of others' servers. 
I believe that we share opinion that restricting own users to sending from my_networks and/or authenticated clients
works perfectly to stop getting spam from [hidden email] to [hidden email].

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
In reply to this post by Noel Jones-2
W dniu 2009-03-03 18:41, Noel Jones pisze:
> Some legit "reminder" type services, some meeting notifications, and
> other legit mail might arrive with you as the sender.  Maybe not best
> practices, but it's legit mail and such a policy will reject it.
Why would someone want to fake sender address? Is this really legit mail
when one has (envelope!) sender address spoofed? I've no idea why should
I get reminder from myself. If xyz is this service provider I want to
get reminder from sth@xyz.

> You can send yourself mail via eg. gmail or your home ISP with your
> postfix domain as sender address.  Some people really do this.
And why would I do that? If my ISP would restrict to send only via their
SMTP server, I'd use webmail. And I have no idea why would one allow
relaying via their SMTP server for everyone. And if not for everyone,
then ISP should do address rewriting for their users. That's it. And
that still doesn't change my point of view - broken configuration
doesn't always give you legit mail.
If one still wants to use other SMTP server to send mail with spoofed
address, why just not add this SMTP server's IP to my_networks?

> The "some amount" of legit mail you will reject is highly dependent on
> your users. Some sites will see quite a bit, others very little.  Some
> people consider this a horrible idea, others a useful policy with an
> acceptable risk.  You get to pick which side of the fence you live on.
I cant's see any risk anyways, not just in place. And it's possible that
zen BL will stop more "legit" mails (depends on what one means by "legit
mail", maybe there are people who read those "I'll give you $1billion"
mails). If I'm wrong, please point it out, let me learn.


Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Noel Jones-2
In reply to this post by Dave Johnson-2
> ------- Original Message -------
> From: Paweł Leśniak <[hidden email]>
> I cant's see any risk anyways, not just in place. And it's possible that
> zen BL will stop more "legit" mails (depends on what one means by "legit
> mail", maybe there are people who read those "I'll give you $1billion"
> mails). If I'm wrong, please point it out, let me learn.
>
>
> Pawel Lesniak
>


I can state with authority that mail with sender==recipient is not universally 100% spam, and such a policy would likely have a much higher false positive rate than zen.  

You can argue it's a misconfiguration of the sender, but a mail admin's job is to receive legit mail.  

but you're welcome to reject mail on any basis you see fit.  a small site can probably implement this policy with no noticeable problems.  

  -- Noel Jones  
Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
>
> I can state with authority that mail with sender==recipient is not
> universally 100% spam, and such a policy would likely have a much
> higher false positive rate than zen. You can argue it's a
> misconfiguration of the sender, but a mail admin's job is to receive
> legit mail. but you're welcome to reject mail on any basis you see
> fit. a small site can probably implement this policy with no
> noticeable problems.

Sure. I'm sending myself emails sometime. But I'm using server which is
permitted to send with address from my domain. So that's surely not 100%
spam when sender eq recipient.
But then we come to definition of spam. It's in simple words unwanted
message. And when someone spoofs my email address, it's certainly not
obeying with my image of legit mail. If I'm calling someone, I'm not
presenting myself as John Johnson. Maybe some people do...
I think you can't give any example that one ^have to^ use my email
address when sending msg to me. You didn't convince me that I'm
rejecting any legit mail by rejecting not authenticated users.

Also IMHO I'll get much more "false positives" with zen then with
authentication if for example I'd be interested in getting money and
medicines offers. We get here to definition of "false positives" which
can be very different for different customers. And that leads as to
another problem whether we consider authentication at customer level (or
server serving SMTP for just single company) or site-wide (in terms of
many customers with single configuration).

Coming back to large ISPs. After checking few "emails for everyone"
providers in Poland I can tell that all of them do relay only for
domains they serve. And it's not common for Internet Access Providers to
block outgoing connections to port 25, still I mean here, in Poland. So
I think that situations pointed by you are rather rare. I don't know of
any, so I'm fine with rejecting 0 legit mails at my place by using smtp
authentication.

Pawel Lesniak


Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Noel Jones-2
Paweł Leśniak wrote:
> I think that situations pointed by you are rather rare.

I see them often enough here that I can't reject based solely
on this criteria, but I do add a couple spamassassin points.
If it's rare at your site, lucky you.

> I don't know of
> any, so I'm fine with rejecting 0 legit mails at my place by using smtp
> authentication.

This discussion is specifically about unauthenticated,
non-mynetworks mail.

   -- Noel Jones

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

/dev/rob0
In reply to this post by Paweł Leśniak
On Wed March 4 2009 08:48:18 Paweł Leśniak wrote:
> But then we come to definition of spam. It's in simple words unwanted
> message.

Too simple, and not correct. The true definition of spam is UBE:
unsolicited bulk email. Most spammers put out messages that a tiny
percentage of recipients want to see. It's how they keep making money
at it.

Postmasters who fail to understand what spam is contribute to the
problem, which is this: email has become nearly unusable for many
people, and would be unusable for everyone without sane strategies to
control the spew. I bet 95% of all SMTP traffic is abuse.

> Also IMHO I'll get much more "false positives" with zen then with
> authentication if for example I'd be interested in getting money and
> medicines offers. We get here to definition of "false positives"
> which can be very different for different customers. And that leads

For the most part, I don't care what the end user thinks, for reasons
implied above. If they solicited email from a legitimate (i.e., not
listed on SBL and not using zombies) bulk sender, they'll get it. If
they solicited email from a spammer, oops, it's blocked.

We all owe it to the Internet to limit spammers' access to our
clue-deprived users who might otherwise help keep them in business.

I try to explain it to them. No, it's not easy. No, I am not managing
any large sites at the moment, but if I was, I'd put up explanations
with links on a http://postmaster.example.com/ Web site.

Most people who claim that Zen gives "false positives" are not using
reject_rbl_client properly. Obviously, you do not reject_rbl_client
before permit_sasl_authenticated. But in your case I don't know what
you're saying. I think the issue of authentication that you bring up
might be irrelevant, except perhaps for the narrow "issue" of sender
equals recipient. I haven't noticed a significant problem with such
spam, which is probably attributable to Zen.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
On Wed March 4 2009 08:48:18 Paweł Leśniak wrote:
  
But then we come to definition of spam. It's in simple words unwanted
message.
    

Too simple, and not correct. The true definition of spam is UBE: 
unsolicited bulk email. Most spammers put out messages that a tiny 
percentage of recipients want to see. It's how they keep making money 
at it.
  
And where do you see the difference between unwanted message and unsolicited bulk email? Word bulk here does not matter in terms of single email address - you don't know (often) if this is one message of many sent or just a single mail, as long as given sender gets blacklisted or you start getting same mail at many different addresses.
Postmasters who fail to understand what spam is contribute to the 
problem, which is this: email has become nearly unusable for many 
people, and would be unusable for everyone without sane strategies to 
control the spew. I bet 95% of all SMTP traffic is abuse.
  
At my servers it's about 90-95% percent of connections which get rejected.

Also IMHO I'll get much more "false positives" with zen then with
authentication if for example I'd be interested in getting money and
medicines offers. We get here to definition of "false positives"
which can be very different for different customers. And that leads
    

For the most part, I don't care what the end user thinks, for reasons 
implied above. If they solicited email from a legitimate (i.e., not 
listed on SBL and not using zombies) bulk sender, they'll get it. If 
they solicited email from a spammer, oops, it's blocked.

We all owe it to the Internet to limit spammers' access to our 
clue-deprived users who might otherwise help keep them in business.

  
true
I try to explain it to them. No, it's not easy. No, I am not managing 
any large sites at the moment, but if I was, I'd put up explanations 
with links on a http://postmaster.example.com/ Web site.

Most people who claim that Zen gives "false positives" are not using 
reject_rbl_client properly. Obviously, you do not reject_rbl_client 
before permit_sasl_authenticated. But in your case I don't know what 
you're saying. I think the issue of authentication that you bring up 
might be irrelevant, except perhaps for the narrow "issue" of sender 
equals recipient. I haven't noticed a significant problem with such 
spam, which is probably attributable to Zen.
  
I'm not saying zen gives "false positives" which I (or better users of my servers)  think are not spam. But if one says that mail sent with spoofed sender is correct then it's not fine with me.
I do not allow mails from client addresses without DNS entries (why don't they use correctly configured mailserver), etc. One can say that I'm rejecting many false positives. Maybe. But I'm rejecting those messages. If sender wants to send legitimate email to me and gets rejected, he should get reply from his server about rejection. If this is the case, then "the ball is on his side". In terms of business mails, one will say that after rejection, the other side will just think we are not worth cooperation. That's not true, because it's better to get rejection instantly then wait few days while recipients finds the message in spam folder for example.

Looking at first email in thread carefully you'd see that Dave has (or had) problem with spam sent from [hidden email] to [hidden email]. And that's the case where authentication will do the job perfectly - IMHO way better then zen.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Charles Marcus
On 3/4/2009, PaweB Le[niak ([hidden email]) wrote:
> Looking at first email in thread carefully you'd see that Dave has
> (or had) problem with spam sent from [hidden email] to [hidden email]. And
> that's the case where authentication will do the job perfectly - IMHO
> way better then zen.

You do realize that if you did that you wouldn't be able to receive your
own messages from mail lists such as this one, correct?

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Paweł Leśniak
On 3/4/2009, PaweB Le[niak ([hidden email]) wrote:
  
Looking at first email in thread carefully you'd see that Dave has 
(or had) problem with spam sent from [hidden email] to [hidden email]. And 
that's the case where authentication will do the job perfectly - IMHO
way better then zen.
    

You do realize that if you did that you wouldn't be able to receive your
own messages from mail lists such as this one, correct?

  
How come?

Mar  4 20:50:50 lola amavis[15332]: (15332-05) FWD via SMTP: [hidden email] -> [hidden email],BODY=7BIT 250 2.6.0 Ok, id=15332-05, from MTA([127.0.0
.1]:10025): 250 2.0.0 Ok: queued as EACA754205

And here restrictions (only recipient - not using any other):
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_hostname, reject_unauth_destination, reject_unlisted_sender, check_sender_access hash:/etc/postfix/restricted_senders.map, reject_sender_login_mismatch, check_client_access pcre:/etc/postfix/check_client_fqdn.pcre, check_recipient_access hash:/etc/postfix/restricted_recipients.map, reject_rbl_client zen.spamhaus.org, check_greylist

/etc/postfix/restricted_senders.map:
lesniakowie.com 554 Prosze wlaczyc autentykacje SMTP / Please enable SMTP authentication

I'm getting all messages without problems. Also those sent by myself.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

mouss-4
In reply to this post by Paweł Leśniak
Paweł Leśniak a écrit :
> W dniu 2009-03-03 18:41, Noel Jones pisze:
>> Some legit "reminder" type services, some meeting notifications, and
>> other legit mail might arrive with you as the sender.  Maybe not best
>> practices, but it's legit mail and such a policy will reject it.
> Why would someone want to fake sender address? Is this really legit mail
> when one has (envelope!) sender address spoofed? I've no idea why should
> I get reminder from myself. If xyz is this service provider I want to
> get reminder from sth@xyz.
>

When you send us mail, you give your mailer (thunderbird, outlook, ...)
the right to send the mail on behalf of you.

now, If I click on a "send this to your friend" link, what is the
difference? why shouldn't I be able to send as myself while clicking on
a link hosted by another organisation.

so if there were no spam, this practice would be ok. now, spam has
killed a lot of functionality... so sending behalf of someone has become
too complex.

>> You can send yourself mail via eg. gmail or your home ISP with your
>> postfix domain as sender address.  Some people really do this.
> And why would I do that?

I do this. I don't care how I send mail. I use my "profile". I will not
sends [hidden email] when I post via my free.fr account,
[hidden email] when I send from a hotel, ... etc.

> If my ISP would restrict to send only via their
> SMTP server, I'd use webmail.

feel free. now webmail is a lot less secure than MUA mail. so I still
prefer MUA mail with SASL/TLS...

> And I have no idea why would one allow
> relaying via their SMTP server for everyone. And if not for everyone,
> then ISP should do address rewriting for their users.

No. if rewrite is needed, then something is fundamentally broken. work
should be done at the source except if not possible. intermediary
systems should not need a lot of resources. otherwise, every time you
design a system, you need to cope with all intermediary systems that
might be added some day.

> That's it. And
> that still doesn't change my point of view - broken configuration
> doesn't always give you legit mail.

This has nothing to do with broken configs.

> If one still wants to use other SMTP server to send mail with spoofed
> address, why just not add this SMTP server's IP to my_networks?
>

I don't see what mynetworks and IPs come to do with sender addresses.
don't add unnecessary coupling.

>> The "some amount" of legit mail you will reject is highly dependent on
>> your users. Some sites will see quite a bit, others very little.  Some
>> people consider this a horrible idea, others a useful policy with an
>> acceptable risk.  You get to pick which side of the fence you live on.
> I cant's see any risk anyways, not just in place. And it's possible that
> zen BL will stop more "legit" mails (depends on what one means by "legit
> mail", maybe there are people who read those "I'll give you $1billion"
> mails). If I'm wrong, please point it out, let me learn.
>

I don't know how you define legit, but the way I see it, I haven't seen
a zen FP, but I have seen cases when senders have been used from
"different" networks.
Reply | Threaded
Open this post in threaded view
|

RE: Spam attacks

MacShane, Tracy
In reply to this post by Paweł Leśniak

        From: [hidden email]
[mailto:[hidden email]] On Behalf Of Pawel Lesniak
        Sent: Wednesday, 4 March 2009 7:32 PM
        To: postfix users list
        Subject: Re: Spam attacks
       
       
        W dniu 2009-03-03 23:34, MacShane, Tracy pisze:

               
        > We have a very clear policy that users are only
permitted to relay mail
                from our networks.  

        So you too advocate (if I clearly understand you) my point of
view, where those "legit mails", which Noel was talking about, are just
misconfigurations of others' servers.  
        I believe that we share opinion that restricting own users to
sending from my_networks and/or authenticated clients works perfectly to
stop getting spam from [hidden email] to [hidden email].
       
        Pawel Lesniak

=================

Actually, no, I wouldn't go that far. I'm fortunate in that I can
dictate such a policy, because it's existed since we've had email in
this organisation (well before my time), and we don't generally have
users subscribing to mailers that use this technique to get the mail
through. I do think it's a silly practice, but it's not technically a
"misconfiguration", nor is it necessarily spam, if a user signed up to
such a service.

For my organisation, it works perfectly as far as it goes, but that's
because of the established history and _clear policy_. We may one day
encounter a situation where we need to create an exemption for a
specific purpose. We only catch a couple of hundred or so messages a day
using this measure at present (it was higher when the botnets were more
active, and before we implemented Fail2ban), but that's a couple of
hundred lookups to Zen we don't have to do each day (not even 0.5% of
the total, though).
       
       

Reply | Threaded
Open this post in threaded view
|

Re: Spam attacks

Mihira Fernando
In reply to this post by Paweł Leśniak
On Wednesday 04 March 2009 20:18:18 Paweł Leśniak wrote:
[snip]
> Sure. I'm sending myself emails sometime. But I'm using server which is
> permitted to send with address from my domain. So that's surely not 100%
> spam when sender eq recipient. But then we come to definition of spam. It's
in simple words unwanted message. And when someone spoofs my email address,
it's certainly not obeying with my image of legit mail
[snip]

Have you ever tried sending an e-greeting to someone via 123greeting.com or
some other similar site ?

Regards,
Mihira.
12