frank -
nope. we did a hard restart.
../surgemail_stop.sh (wait until done)
../surgemail_start.sh
`tellmail reload` is the equivalent of sending a `kill HUP` or in apache
`apache2ctl graceful`. it just reloads and doesn't start and stop. i use
`tellmail reload` after editing surgemail.ini manually, since i'm a
command line bigot :-)
this particular spammer really had their act together. i looked up the
ips that they were spoofing. even though ya.ru is in russia (a spawn of
yandex.ru - kinda like a google), the ips were in the netherlands,
germany and the us. i wonder how they can do that.
<rant>
frankly, getting sick of dealing with this s**t. i'm a web development
and hosting company, not an isp. and i don't make a cent on the email
service that i provide as a courtesy to my 600+ customer users. but i
sure spend a huge amount of time supporting this.
</rant>
if chris can chime in and tell me how i can really cut this crap off,
i'd be delighted.
david camm
advanced web systems
keller, tx
On 5/7/2015 5:17 PM, Frank Bulk wrote:
> David,
>
> When you say "restarted", you mean "tellmail reload", right? Because stopping surgemail and starting surgemail will kill those authenticated sessions.
>
> Frank
>
> -----Original Message-----
> From: David Camm [mailtoHIDDEN@advwebsys.com]
> Sent: Thursday, May 07, 2015 12:53 PM
> To: surgemailHIDDEN@etwinsite.com
> Subject: Re: [SurgeMail List] Suspended account still sending mail
>
> we had a similar problem this morning -
>
> a spammer at ya.ru apparently got hold of an account's password and
> opened several smtp sessions using 5 different spoofed - we think - ip
> addresses. the reason we believe they were spoofed is that entering
> them into iptables did not stop the traffic.
>
> since the sessions were already authenticated, changing the account
> password and restarting didn't help.
>
> adding the domain name into the g_ban_from list and restarting didn't
> help either.
>
> ultimately, we added an mfilter rule:
>
> if (rexp(from,'HIDDEN@u')) then
> drop "Spammer Address in From"
> end if
>
> which seemed to work.
>
> seems to me there's got to be a better way to kill smtp connections that
> are known to be 'bad.'
>
> david camm
> advanced web systems
> keller, tx
>
>
>
> On 5/5/2015 4:14 PM, Frank Bulk wrote:
>> Chris,
>>
>> Thanks, that’s good to know. Today we move the files out as the file
>> system level, and then restart Surgemail so that if there any SMPT
>> sessions in progress those are close and if there are any
>> authenticated SMTP sessions those are gone. We found that just
>> changing the password using tellmail was insufficient.
>>
>> Are we getting closer to the point where we can deal with a spammer
>> who has one of our customer’s compromised credentials and not have to
>> stop and then start Surgemail?
>>
>> Frank
>>
>> *From:*Surgemail Support [mailto:surgemailHIDDEN@t@netwinsite.com]
>> *Sent:* Sunday, May 03, 2015 6:00 PM
>> *To:* surgemailHIDDEN@etwinsite.com
>> *Subject:* Re: [SurgeMail List] Suspended account still sending mail
>>
>> Just re-posting this response to get it in the archive.
>>
>> This turned out to be an issue with messages currently being sent
>> being 'locked' in future builds it will correctly delete messages
>> which are
>> being 'sent' when the tellmail delete_contains command is used.
>>
>> ChrisP.
>>
>>
>> On 4/15/2015 8:03 PM, Tom Cross wrote:
>>
>> Hi
>>
>> A customer had a virus sending 100's of emails out.
>>
>> I suspended the account, deleted the mail queue for the user and
>> restarted the service.
>>
>> I go into the Mail queue and there they are again 79 mails.
>>
>> Delete again.
>>
>> 10 min later they are back.
>>
>> Help please.
>>
>> tom cross
>> Partner Synergist
>> 0418 295 336
>> HIDDEN@tml.net.au <mailto:tomc@html.net.au>
>>
>>
>>
>>
>
>
|
