On Tue, Feb 20, 2007 at 02:16:49PM +0100, the unit calling itself Peter N. M.
Hansteen wrote:
Isn't this a bit over the top?
Well, people don't read these strings at all unless they're looking at
spamd source code or doing a telnet yourhost.tld smtp for debugging
purposes. The message
On 3/10/07, J Moore [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2007 at 02:16:49PM +0100, the unit calling itself Peter N. M.
Hansteen wrote:
Isn't this a bit over the top?
Well, people don't read these strings at all unless they're looking at
spamd source code or doing a telnet yourhost.tld
On 3/10/07, Darren Spruell [EMAIL PROTECTED] wrote:
On 3/10/07, J Moore [EMAIL PROTECTED] wrote:
...
So - are you saying that these strings will never show up in the headers
of an email message returned to a legitimate sender?
No. Headers and message are sent in the SMTP DATA portion. The
On 3/10/07, Philip Guenther [EMAIL PROTECTED] wrote:
On 3/10/07, Darren Spruell [EMAIL PROTECTED] wrote:
On 3/10/07, J Moore [EMAIL PROTECTED] wrote:
...
So - are you saying that these strings will never show up in the headers
of an email message returned to a legitimate sender?
No.
On 3/10/07, Darren Spruell [EMAIL PROTECTED] wrote:
On 3/10/07, Philip Guenther [EMAIL PROTECTED] wrote:
...
They (the text in SMTP responses) won't show up in the headers, but
they may show up in the body of DSNs or bounces generated by the
client. Yes, that can happen even when the
J Moore [EMAIL PROTECTED] writes:
So - are you saying that these strings will never show up in the headers
of an email message returned to a legitimate sender?
The way spamd works your message does not get handled by a real smtp
daemon until it clears greylisting, in contrast to the various
On Sat, Mar 10, 2007 at 11:29:04PM +0100, Peter N. M. Hansteen wrote:
J Moore [EMAIL PROTECTED] writes:
So - are you saying that these strings will never show up in the headers
of an email message returned to a legitimate sender?
The way spamd works your message does not get handled by
Darrin Chandler [EMAIL PROTECTED] writes:
I suspect I'm not the only person who's had the spamd messages come back
from someone who's message didn't come through. While in normal
circumstances these messages don't show, there are enough email
providers out there (large, commonly used ones)
On Ter, 2007-02-20 at 17:56 -0700, Darren Spruell wrote:
The fact remains that after 3 and a half years spammers as a whole
have not outwitted greylisting. The facts speak for themselves; those
who actually implement spamd see a sharp reduction in spam deliveries.
I think they're gradually
On Tue, Feb 20, 2007 at 03:07:45PM -0600, Jacob Yocom-Piatt wrote:
Theo de Raadt wrote:
In fact, there are spammers who ARE noticing that greylisting servers
look (or behave) different, and they are disconnecting and not sending
spam through them. Thus, no spam is delivered.
i have seen a
J Moore [EMAIL PROTECTED] writes:
Isn't this a bit over the top?
Well, people don't read these strings at all unless they're looking at
spamd source code or doing a telnet yourhost.tld smtp for debugging
purposes. The message you quote here is essentially just a preserved
version of the telnet
On 2/20/07, J Moore [EMAIL PROTECTED] wrote:
I was under the impression that spamd was supposed to politely defer
connections from unknown/greylisted hosts.
Given the '451' response in the SMTP conversation, it is a relatively
polite and benign way to defer connections. I doubt a sending MTA
Rogier Krieger wrote:
Humans shouldn't be connecting to port 25 in any case, unless when
they know what they're doing (and know why they're connecting). End
user connections are what the submission port (589) is for.
# grep submission /etc/services
submission 587/tcp
submission
Rogier Krieger wrote:
End user connections are what the submission port (589) is for.
Small correction: it's 587, not 589.
---
Lars Hansson
On 2/20/07, Jimmy Mdkeld | Loopia AB [EMAIL PROTECTED] wrote:
Rogier Krieger wrote:
End user connections are what the submission port (589) is for.
# grep submission /etc/services
submission 587/tcp
submission 587/udp
As I ment to say, port 587 ;)
Apparently, it is time for my
On Tue, 20 Feb 2007, Peter N. M. Hansteen wrote:
J Moore [EMAIL PROTECTED] writes:
Isn't this a bit over the top?
Well, people don't read these strings at all unless they're looking at
spamd source code or doing a telnet yourhost.tld smtp for debugging
purposes. The message you quote
On Feb 20, 2007, at 10:00 AM, Woodchuck wrote:
On Tue, 20 Feb 2007, Peter N. M. Hansteen wrote:
J Moore [EMAIL PROTECTED] writes:
Isn't this a bit over the top?
Well, people don't read these strings at all unless they're
looking at
spamd source code or doing a telnet yourhost.tld smtp
In the case of a greylisting type of solution, it seems that
identification would be especially devastating since the work-around
is so trivial. Unless my understanding is very wrong, the whole
effectiveness of the solution depends on the spammers not realizing
the difference between
I was thinking the exact same thing.
A number of our customers use the ability to customize their SMTP
banner via our products in order to avoid some very basic system
identification by spammers (Cisco PIX does this too for instance, but
in a very broken and disruptive way). It
On Feb 20, 2007, at 11:54 AM, Theo de Raadt wrote:
In the case of a greylisting type of solution, it seems that
identification would be especially devastating since the work-around
is so trivial. Unless my understanding is very wrong, the whole
effectiveness of the solution depends on the
I haven't looked at the implementation in OpenBSD extensively, but at
Well, perhaps you should, instead of commenting before you do.
a basic level there are two portions, the greylist function, and the
waste their time function, yes? I'm talking about bypassing the
first, not the
On 2/20/07, Brian Keefer [EMAIL PROTECTED] wrote:
In the case of a greylisting type of solution, it seems that
identification would be especially devastating since the work-around
is so trivial. Unless my understanding is very wrong, the whole
effectiveness of the solution depends on the
On Tue, 20 Feb 2007, Theo de Raadt wrote:
In the case of a greylisting type of solution, it seems that
identification would be especially devastating since the work-around
is so trivial. Unless my understanding is very wrong, the whole
effectiveness of the solution depends on the
On Feb 20, 2007, at 12:36 PM, Darren Spruell wrote:
On 2/20/07, Brian Keefer [EMAIL PROTECTED] wrote:
In the case of a greylisting type of solution, it seems that
identification would be especially devastating since the work-around
is so trivial. Unless my understanding is very wrong, the
Theo de Raadt wrote:
If a spammer knows I am running spamd because he can detect it, and
then disconnects, no spam makes it througg -- no spam is delivered.
There is no workaround for the spammer, except to act as a regular
follow the RFC, and retry, which most of the spammers don't do (and
I run spamd up front with a secondary spam filter behind it. My
secondary filter receives 90% less spam then before I started running
spamd. With that big of a drop I can only say wonderful things about
OpenBSD's spamd. It just plain works. When things start getting back
to pre spamd
Jacob Yocom-Piatt wrote:
i have seen a number of spammer outfits doing this: following
the RFC and retrying until the spam gets though and they're
whitelisted, then they're free to push crap through. any
thoughts on how to best combat this behavior besides
spamassassin + amavisd (i.e. wasting
i have seen a number of spammer outfits doing this: following the RFC
and retrying until the spam gets though and they're whitelisted, then
they're free to push crap through. any thoughts on how to best combat
this behavior besides spamassassin + amavisd (i.e. wasting cpu cycles
and
On Tue, 20 Feb 2007 12:57:54 -0800, Brian Keefer [EMAIL PROTECTED]
said:
On Feb 20, 2007, at 12:36 PM, Darren Spruell wrote:
On 2/20/07, Brian Keefer [EMAIL PROTECTED] wrote:
In the case of a greylisting type of solution, it seems that
identification would be especially devastating since
All I have to say about this thread ishey Theo nice to see you back, I
needed some comic relief today. Oh and my feelings about being abrasive
towards spammers is fuck 'em, I hate spammers. I wish spamd could shit on
their servers but that's not a settable option. Maybe spamd -P would poop
on
On Feb 20, 2007, at 1:51 PM, [EMAIL PROTECTED] wrote:
On Tue, 20 Feb 2007 12:57:54 -0800, Brian Keefer [EMAIL PROTECTED]
said:
Now they've evolved to using botnets and the vast majority of spam
comes from such systems, so the bandwidth costs are gone and the
hosting costs are pretty much
On Ter, 2007-02-20 at 15:07 -0600, Jacob Yocom-Piatt wrote:
i have seen a number of spammer outfits doing this: following the RFC
and retrying until the spam gets though and they're whitelisted, then
they're free to push crap through. any thoughts on how to best combat
this behavior besides
On 2/20/07, Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote:
On Ter, 2007-02-20 at 15:07 -0600, Jacob Yocom-Piatt wrote:
i have seen a number of spammer outfits doing this: following the RFC
and retrying until the spam gets though and they're whitelisted, then
they're free to push crap
I was testing a new DNSBL, and got the test results shown below:
I was under the impression that spamd was supposed to politely defer
connections from unknown/greylisted hosts. The dialogue below suggests
that the assumption is that the unknown host is a spammer (which is true
99% of the time,
34 matches
Mail list logo
