>At 02:31 10-03-2014, Marcus MERIGHI wrote:
>>Which to me still seems unfixable as you did not provide anything
>>tangible.
>
>Some people use SPF.
SPF certainly looks like a useful tool for helping with checking
sender identity, but it doesn't look even close to trivial to
implement, and there ma
On 03/04/14 00:44, Marcus MERIGHI wrote:
as I read this (thanks for the link) there is no real solution to the
problem. Under "Reducing the problem" it says:
Checking bounce recipients
Mail servers sending email bounce messages can use a range of measures
to judge whether a return address has b
At 02:31 10-03-2014, Marcus MERIGHI wrote:
Which to me still seems unfixable as you did not provide anything
tangible.
Some people use SPF.
Regards,
-sm
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Hi
>> [snip]
>> Given the similarities in the feel of the conf file to pf.conf I would
>> try to tend towards that (well tested) model where possible to try and
>> keep the confusion for new users as low as possible.
>>
>
>I don't really agree here, the first match approach is much simpler when
>
On Mon, Mar 10, 2014 at 08:52:26AM +, John Cox wrote:
> Hi
>
> >>[snip]
> >> as knobs for global default overrides, which can be overriden at the
> >> rule level, like we do for "expire"
> >
> >All good points, and I'm inclined to agree with you that we receive
> >some nice granularity by doin
s...@resistor.net (SM), 2014.03.04 (Tue) 13:12 (CET):
> At 00:44 04-03-2014, Marcus MERIGHI wrote:
> >as I read this (thanks for the link) there is no real solution to the
> >problem. Under "Reducing the problem" it says:
> >
> >Checking bounce recipients
> >Mail servers sending email bounce messag
On Sun, Mar 09, 2014 at 08:25:10PM +0100, Jason A. Donenfeld wrote:
> On Wed, Mar 5, 2014 at 2:33 AM, Jason A. Donenfeld wrote:
> > On Wed, Mar 5, 2014 at 1:44 AM, Gilles Chehade wrote:
> >> if at the listen-level, we decide that it is not possible to have the
> >> mechanism apply to a specific d
Hi
>>[snip]
>> as knobs for global default overrides, which can be overriden at the
>> rule level, like we do for "expire"
>
>All good points, and I'm inclined to agree with you that we receive
>some nice granularity by doing it on accept rather than on listen
>(since you've already solved the con
On Wed, Mar 5, 2014 at 2:33 AM, Jason A. Donenfeld wrote:
> On Wed, Mar 5, 2014 at 1:44 AM, Gilles Chehade wrote:
>> if at the listen-level, we decide that it is not possible to have the
>> mechanism apply to a specific domain, it applies to all domains that
>> will be match on that interface.
>>
Hi
> [snip]
>if at the listen-level, we decide that it is not possible to have the
>mechanism apply to a specific domain, it applies to all domains that
>will be match on that interface.
>
> listen on lo0 bounce all-content
> listen on fxp0 bounce headers-only
>
> accept from any for domain
On Wed, Mar 5, 2014 at 1:44 AM, Gilles Chehade wrote:
> if at the listen-level, we decide that it is not possible to have the
> mechanism apply to a specific domain, it applies to all domains that
> will be match on that interface.
> if at the rule-level, we decide that we can apply this to a spec
On Tue, Mar 04, 2014 at 12:25:58AM +0100, Jason A. Donenfeld wrote:
>
> [...]
>
> OpenSMTPD will generate bounces in lots of contexts. It doesn't make
> sense, for example, to add the flag to "accept", since if you accept
> mail for @poolp.org, but ploop.org also points to the same IP, and
> someo
Hi Marcus,
At 00:44 04-03-2014, Marcus MERIGHI wrote:
as I read this (thanks for the link) there is no real solution to the
problem. Under "Reducing the problem" it says:
Checking bounce recipients
Mail servers sending email bounce messages can use a range of measures
to judge whether a return a
Hello backscatterers (:-),
jab...@serversave.us (Jason Barbier), 2014.03.03 (Mon) 18:47 (CET):
> So reading this also this type of spam bounce has a common name, its called
> backscattering (https://en.wikipedia.org/wiki/Backscatter_%28email%29).
as I read this (thanks for the link) there is no
On Mon, Mar 3, 2014 at 8:17 PM, Gilles Chehade wrote:
> I understand the issue but the way you're presenting it makes it look
> like everyone is affected and can be abused by spammers, I'd like to
> clarify that this "easy trick" requires you to have a specific setup
> that involves both redirect
On 03/03/14 14:02, Hugo Osvaldo Barrera wrote:
On 2014-03-03 20:35, Gilles Chehade wrote:
On Mon, Mar 03, 2014 at 11:32:44AM -0800, Jason Barbier wrote:
Well yeah it would be somthing simple like that I think it would
make more sense on listen to be honest so
Listen on egress DSN {Full, Rejec
The reason I would think it makes more sense there is determining the
direction of it. But to be honest thinking about it some more it may be
as a rule we would just need a way to determine directionality since we
may want to have a way to cross domain boundries with the messages,
maybe having
On Mon, Mar 03, 2014 at 11:32:44AM -0800, Jason Barbier wrote:
> Well yeah it would be somthing simple like that I think it would
> make more sense on listen to be honest so
>
> Listen on egress DSN {Full, Reject, Header-only, Disable}
>
> Full is full messages with headers and the like
> Reject
Well yeah it would be somthing simple like that I think it would make
more sense on listen to be honest so
Listen on egress DSN {Full, Reject, Header-only, Disable}
Full is full messages with headers and the like
Reject would make the connector reject anything that gets bounced or
requires a D
On Mon, Mar 03, 2014 at 09:47:06AM -0800, Jason Barbier wrote:
>
> [...]
>
> by default. Honestly users should beable to turn this on and off
> based on the direction of the mail. internally it is useful to have
> it spit back the message, headers, and the raw error that the MTA
> returned. Externa
On Mon, Mar 03, 2014 at 06:16:03PM +0100, Jason A. Donenfeld wrote:
> Hi folks,
>
Hi,
> Spammers have an easy trick against OpenSMTPD: they send a message
> that bounces for some reason (say, it's forwarded to another MTA that
> rejects it on on the basis of it being spam), and the bounce messag
So reading this also this type of spam bounce has a common name, its
called backscattering
(https://en.wikipedia.org/wiki/Backscatter_%28email%29). There is
actually a blacklist for this and quite a few companies use it, as well
as greylisting software will check for it. We for sure want to mak
A ticket: https://github.com/poolpOrg/OpenSMTPD/issues/429
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Hi folks,
Spammers have an easy trick against OpenSMTPD: they send a message
that bounces for some reason (say, it's forwarded to another MTA that
rejects it on on the basis of it being spam), and the bounce message
then contains the original spam message. Egress spam filters on
various hosting ne
24 matches
Mail list logo
