On Thursday 19 October 2006 06:39, Jo Rhett took the opportunity to say:
> Magnus Holmgren wrote:
> > OK, the attacker might have 100 zombies on different ISPs, with each
> > ISP's smarthost helping amplify the attack a bit. But does that really
> > count? The servers making the callouts aren't the
Magnus Holmgren wrote:
OK, the attacker might have 100 zombies on different ISPs, with each ISP's
smarthost helping amplify the attack a bit. But does that really count? The
servers making the callouts aren't the ones which are amplifying.
You really don't have to deal with spam at your day jo
On Wednesday 18 October 2006 19:41, Jo Rhett took the opportunity to say:
> Magnus Holmgren wrote:
> > The thing with e.g. the DNS-based DDoS attacks that became common a while
> > ago is that there is a considerable bandwidth amplification; you send a
> > small query packet with a forged sender ad
On Tuesday 17 October 2006 19:33, Jo Rhett took the opportunity to say:
Send a bunch of spam with a single forged sender address to a lot of
sites that do sender verification. Watch their mail server fall down.
I can assure you that even with modern hardware, no e-mail MTA available
today can ha
On Tuesday 17 October 2006 19:33, Jo Rhett took the opportunity to say:
> Marc Perkel wrote:
> > Not really. If somene had the bandwidth to cause a denial of service
> > through sender verification they could do it more easlly by just
> > attacking the target directly. No one is going to use sender
> >> You mean, a 5xx (permanent) error?
> >>
> >> Most sites don't use permanent errors for unknown mailboxes: the
> >> rfc-suggests error code for this case is a temporary one (but
> maybe I didn't
> >> recall it good enough).
> >>
> >> giampaolo
> >> '
>
> Hi,
>
> I have recently played with
>
> My incoming servers know literally nothing about which users have valid
> addresses and which do not. All these servers do is accept or reject
> inbound mail based on a (long) list of SMTP-level rules and forward the
> messages that are accepted to another machine for SA and virus scanning.
>
>>
>>
>> Just to know, how exim's sender verification function copes with
>> greylisting? I mean, at the first time exim attempts to check some user
>> mailbox on a given mx with greylisting functions, it gets a 450 reply code.
>> Does exim assumes the sender address is forged in that case?
>>
Kelson wrote:
Marc Perkel wrote:
Generally a dictionary attach uses randon to addresses, not from
addresses. Sender verification works on the from address.
And when your sender verification setup tries to verify a forged From:
address against my server, it uses it as the To: address. Add a
Just to know, how exim's sender verification function copes with greylisting? I mean, at the first time exim attempts to check some user mailbox on a given mx with greylisting functions, it gets a 450 reply code. Does exim assumes the sender address is forged in that case?
Exim sender ver
Marc Perkel wrote:
Generally a dictionary attach uses randon to addresses, not from
addresses. Sender verification works on the from address.
And when your sender verification setup tries to verify a forged From:
address against my server, it uses it as the To: address. Add a bunch
of them t
Giampaolo Tomassoni wrote:
Marc Perkel wrote:
Sender Verification is an Exim trick. What it does is start a sequence
where my server starts to send an email back to the sender address to
see if it's a real email account. But I do a quit after the rctp to:
command. I
Jim Maul wrote:
If you do *recipient* verification as opposed to sender, why would
there be any bounce message at all? reject unknown recipients at smtp
time. Wheres the problem? All sender verification seems to do at this
point is create load on your and other peoples servers, and provid
> Marc Perkel wrote:
> > Sender Verification is an Exim trick. What it does is start a sequence
> > where my server starts to send an email back to the sender address to
> > see if it's a real email account. But I do a quit after the rctp to:
> > command. If the receiving end says the user doesn
Marc Perkel wrote:
Sender Verification is an Exim trick. What it does is start a sequence
where my server starts to send an email back to the sender address to
see if it's a real email account. But I do a quit after the rctp to:
command. If the receiving end says the user doesn't exist then I b
At 08:32 17-10-2006, Dave Pooser wrote:
You think so? By my count, my server is transmitting roughly 80 bytes of
data (HELO, MAIL FROM:, RCPT TO: and QUIT); even with overhead from RBL
checks on your side that shouldn't contribute to any load. It's not like an
evil spammer could carefully synchro
>
> Um, yes. Well, I've seen it DoSed by just attempts to deliver to an
> address that doesn't exist. "User not found" after RCPT TO is the exact
> same traffic load. That was very modern hardware, and it happened just
> a few weeks ago.
>
> Think about it. It doesn't require you to stretch yo
>
> Right. And rate limiting limits the real service. Thus, you have ...
> oh yeah, DENIAL OF SERVICE.
>
> THINK! It's not hard.
>
> --
> Jo Rhett
> Network/Software Engineer
> Net Consonance
Don't assume Jo.
You do not know specifically what I was talking about rate limiting and why
or how.
Marc Perkel wrote:
Jim Maul wrote:
Kelson wrote:
Matt Kettler wrote:
That said, some folks still hate it because you're using some (very
little) of their CPU and network to handle your spam.
Also, a large number of verifications (say, because someone has been
sending lots of spam with for
Marc Perkel wrote:
Generally a dictionary attach uses randon to addresses, not from
addresses. Sender verification works on the from address. And if I
didn't use sender verification it scould result in a bounce message to
the address that I would have verified and the bounce message is a far
w
Marc Perkel wrote:
I'm using Exim which caches sender verification results so if the
attacker uses a single forged address it would only result in a callout
ever 2 hours or so.
You really didn't read that page, did you?
Yes, it works well for you. But if everyone is doing it, it will fail.
Jo Rhett wrote:
Marc Perkel wrote:
Not really. If somene had the bandwidth to cause a denial of service
through sender verification they could do it more easlly by just
attacking the target directly. No one is going to use sender
verification as a DIS tool. It's to inefficient.
What? You
R Lists06 wrote:
Maybe... under extremely special circumstances, yet more realistically not.
Well programmed software can rate limit itself when things look hokey...
Right. And rate limiting limits the real service. Thus, you have ...
oh yeah, DENIAL OF SERVICE.
THINK! It's not hard.
--
J
Marc Perkel wrote:
So if you have a company who is knowingly and deliberately listing
people who they know are in the spam fighting business as spammers, what
No. Just like RFC_POST and RFC_ABUSE they are listing people who
violate a policy. And by using those BLs, I am choosing not to acce
Jim Maul wrote:
Kelson wrote:
Matt Kettler wrote:
That said, some folks still hate it because you're using some (very
little) of their CPU and network to handle your spam.
Also, a large number of verifications (say, because someone has been
sending lots of spam with forged headers) looks s
Dave Pooser wrote:
Have you actually seen a server DOSed by sender callouts, ever? I never have
and I've ever heard of one
Um, yes. Well, I've seen it DoSed by just attempts to deliver to an
address that doesn't exist. "User not found" after RCPT TO is the exact
same traffic load. That
Marc Perkel wrote:
Not really. If somene had the bandwidth to cause a denial of service
through sender verification they could do it more easlly by just
attacking the target directly. No one is going to use sender
verification as a DIS tool. It's to inefficient.
What? You mean the same ineff
Kelson wrote:
Matt Kettler wrote:
That said, some folks still hate it because you're using some (very
little) of their CPU and network to handle your spam.
Also, a large number of verifications (say, because someone has been
sending lots of spam with forged headers) looks suspiciously like a
Matt Kettler wrote:
That said, some folks still hate it because you're using some (very
little) of their CPU and network to handle your spam.
Also, a large number of verifications (say, because someone has been
sending lots of spam with forged headers) looks suspiciously like a
dictionary att
> ...maybe you could be the one to correct their "grammar" as they
> put it and
> they would bless/pay you by pulling your entry...
Ahahah. :)
giampaolo
>
> Yes, I am joking... sort of...
>
> :-)
>
> - rh
>
> --
> Robert - Abba Communications
>Computer & Internet Services
> (509) 624
>
> hat it looks like to me is a way of blacklisting competition to try to
> stear business their way. The only way to get off their lists is to pay
> them money. It looks more like extortion to me.
>
Marc
After reading their EN website, http://www.uceprotect.net/en/
...maybe you could be the
The way I see it is this. I run a spam filtering company. I'm one of the
good guys who are blocking spam. uceprotect.net claims to be a list to
block spammers. I have written them several times and even though they
know that I am not a spammer they refuse to take me off their spammers list.
So
> It's also a good trick to cause a denial of service.
>
> Regards,
> -sm
>
Maybe... under extremely special circumstances, yet more realistically not.
Well programmed software can rate limit itself when things look hokey...
- rh
--
Robert - Abba Communications
Computer & Internet Service
>> I don't know if other MTAs support sender verification but if they
>> don't they should. It's a very good trick for blocking spam at connect time.
>
> It's also a good trick to cause a denial of service.
You think so? By my count, my server is transmitting roughly 80 bytes of
data (HELO, MAIL
SM wrote:
At 20:52 16-10-2006, Marc Perkel wrote:
I don't know if other MTAs support sender verification but if they
don't they should. It's a very good trick for blocking spam at
connect time.
It's also a good trick to cause a denial of service.
Regards,
-sm
Not really. If somene had th
Giampaolo Tomassoni wrote:
Well - if they get it wrong and won't fix it and they are causing my
good emails to bounce for 2500 domains, what am I supposed to do?
Well, Do they in fact "have it wrong"? If their listing criteria
considers sender verification to be
At 20:52 16-10-2006, Marc Perkel wrote:
I don't know if other MTAs support sender verification but if they
don't they should. It's a very good trick for blocking spam at connect time.
It's also a good trick to cause a denial of service.
Regards,
-sm
> > Well - if they get it wrong and won't fix it and they are causing my
> > good emails to bounce for 2500 domains, what am I supposed to do?
> Well, Do they in fact "have it wrong"? If their listing criteria
> considers sender verification to be "mail abuse", well, you fit their
> listing criteri
Marc Perkel wrote:
>
>
> Well - if they get it wrong and won't fix it and they are causing my
> good emails to bounce for 2500 domains, what am I supposed to do?
Well, Do they in fact "have it wrong"? If their listing criteria
considers sender verification to be "mail abuse", well, you fit their
Matt Kettler wrote:
I know who Marc is.. I first "met" him when I was subscribed to sa-dev
a long time ago and tried to defend him in a flame war back in July 2002.
(strangely, the dev-list member arguing strongest against Marc's idea
was actually a contributor in the process of implementing
Marc Perkel wrote:
>
> But it take a lot less CPU that it takes to run it through SA. I
> manage to classify 95% of incomming with Exim rules and I just run SA
> on the remaining 5%. So sender verification works for me. And I
> welcome it when others verify my domains.
I agree.. I don't exactly agr
Rob McEwen wrote:
> Matt Kettler wrote:
>
>> but in this case you gotta admit you're asking for
>> the exact same kind of information as a spammer needs
>>
>
> Marc 's purposes are "innocent", Marc is a trustworthy person,
I know who Marc is.. I first "met" him when I was subscribed to sa-
Matt Kettler wrote:
Marc Perkel wrote:
Matt Kettler wrote:
Marc Perkel wrote:
I'm having problems with my spam filtering servers getting listed on
UCEPROTECT and can't figure out why. Is anyone familiar with how this
blacklist works and w
Marc Perkel wrote:
>
>
> Matt Kettler wrote:
>> Marc Perkel wrote:
>>
>>> I'm having problems with my spam filtering servers getting listed on
>>> UCEPROTECT and can't figure out why. Is anyone familiar with how this
>>> blacklist works and what I need to do to not get listed?
>>>
>>> They seem
Matt Kettler wrote:
>but in this case you gotta admit you're asking for
>the exact same kind of information as a spammer needs
Marc 's purposes are "innocent", Marc is a trustworthy person, and anyone
who has the answer certainly can reply back directly to Marc so as to not
post such sensitive inf
Matt Kettler wrote:
Marc Perkel wrote:
I'm having problems with my spam filtering servers getting listed on
UCEPROTECT and can't figure out why. Is anyone familiar with how this
blacklist works and what I need to do to not get listed?
They seem to hate sender verification - but
Marc Perkel wrote:
> I'm having problems with my spam filtering servers getting listed on
> UCEPROTECT and can't figure out why. Is anyone familiar with how this
> blacklist works and what I need to do to not get listed?
>
> They seem to hate sender verification - but I'm not going to give that up.
I'm having problems with my spam filtering servers getting listed on
UCEPROTECT and can't figure out why. Is anyone familiar with how this
blacklist works and what I need to do to not get listed?
They seem to hate sender verification - but I'm not going to give that
up. What do I need to block
48 matches
Mail list logo
