Mailing List Archive

Jan 5, 2008, 1:04 PM

Post #27 of 47 (13928 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> On Sat, 2008-01-05 at 19:02 +0000, Julian Mehnle wrote:
> > David Woodhouse wrote:
> > > MAIL FROM forgery is simple enough to fix anyway, with schemes such
> > > as BATV and SES which can be implemented unilaterally, without
> > > requiring the world to change.
> >
> > BATV and SES don't prevent MAIL FROM forgery. They merely help
> > _senders_ sort out invalid bounces. They don't do anything for the
> > _receivers_.
>
> Not so.
> [.... SMTP transaction transcript with callback verification demon-
> strating the rejection of an unsigned MAIL FROM address ...]

You said it could be implemented unilaterally, but then you assume that
receivers do callback verification.

> > > why would you need multiple handles for the same sending host?
> >
> > Because of many domains sending through a common host, some domains
> > may be sending mostly spam whereas other may be sending mostly
> > non-spam. Your answer to that is probably: "Why accept mail from a
> > spammy host, even if some mail is good?
>
> You've already ignored my answer to that, conveniently. And that wasn't
> it.

I am sorry, I must have overlooked it. Can you please repeat it? I
promise not to ignore it a second time.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHf/DcwL7PKlBZWjsRAi1TAKCeaxHPg9Ph9Ur5S9+4vJaXAoxG6QCfREjL
yBsaz4wuRvc2qm10+d9ibWs=
=UHkG
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82218980-717f91
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

dwmw2 at infradead

Jan 5, 2008, 1:43 PM

Post #28 of 47 (13936 views)

On Sat, 2008-01-05 at 21:04 +0000, Julian Mehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Woodhouse wrote:
> > On Sat, 2008-01-05 at 19:02 +0000, Julian Mehnle wrote:
> > > David Woodhouse wrote:
> > > > MAIL FROM forgery is simple enough to fix anyway, with schemes such
> > > > as BATV and SES which can be implemented unilaterally, without
> > > > requiring the world to change.
> > >
> > > BATV and SES don't prevent MAIL FROM forgery. They merely help
> > > _senders_ sort out invalid bounces. They don't do anything for the
> > > _receivers_.
> >
> > Not so.
> > [.... SMTP transaction transcript with callback verification demon-
> > strating the rejection of an unsigned MAIL FROM address ...]
>
> You said it could be implemented unilaterally, but then you assume that
> receivers do callback verification.

It _can_ be implemented unilaterally, and it immediately stops you from
receiving bounces to messages you didn't send -- in a way that SPF
doesn't, because there aren't enough people rejecting for SPF failure.

Obviously, for the recipient to _also_ benefit, they'd need to do
_something_ for themselves, and callouts have been a common way of
validating addresses for many years. Sourceforge (and many others)
stopped receiving fake MAIL FROM:<dwmw2@infradead.org> without knowing a
thing about BATV. And it certainly didn't require changes to
long-standing behaviour from uninterested third parties, as SPF does.

I wouldn't _assume_ that the majority of recipients do _any_ form of
sane spam filtering. Too many of them don't, and too many recipients are
actually stupid enough to _act_ on the spam they receive. If we could
just take all those stupid people out back and shoot them, spam wouldn't
be profitable any more and we could ditch the technical measures
altogether :)

> > > > why would you need multiple handles for the same sending host?
> > >
> > > Because of many domains sending through a common host, some domains
> > > may be sending mostly spam whereas other may be sending mostly
> > > non-spam. Your answer to that is probably: "Why accept mail from a
> > > spammy host, even if some mail is good?
> >
> > You've already ignored my answer to that, conveniently. And that wasn't
> > it.
>
> I am sorry, I must have overlooked it. Can you please repeat it? I
> promise not to ignore it a second time.

It's the paragraph after "why would you need multiple handles for the
same sending host?". The one which starts "Although actually..." and
ends "...there's nothing in CSV which prevents that from working."

--
dwmw2

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82224086-7d1340
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

Jan 5, 2008, 2:03 PM

Post #29 of 47 (13914 views)

On Jan 5, 2008 12:25 PM, Mark <admin@asarian-host.net> wrote:

> Edmig wrote:
>

>
> > Why do we care? If Y is reputable, and it says X is OK, we have
> > what we need. If Z is forged, we tell Y, and they fire X.
>
> It'd be a simple matter of granularity. In your example you can either
> trust relay X completely, or not at all. A bit crude, don't ya think?

The granularity of the HELO name is controlled by the sender, as it should
be. If X can't get control of spammer accounts on its webmail servers, or
whatever, it would be very easy for them to use a different HELO name for
those servers. Normal, spam-free senders will want to put everything under
one name, to solidify their reputation. Senders with just a little spam
will want to segregate it as much as possible due to the terrible impact of
a little spam on a good reputation.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82227666-bc5eeb
Powered by Listbox: http://www.listbox.com

Re: Revising SOFTFAIL [ In reply to ]

Jan 5, 2008, 2:34 PM

Post #30 of 47 (13930 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> On Sat, 2008-01-05 at 21:04 +0000, Julian Mehnle wrote:
> > David Woodhouse wrote:
> > > You've already ignored my answer to that, conveniently. And that
> > > wasn't it.
> >
> > I am sorry, I must have overlooked it. Can you please repeat it? I
> > promise not to ignore it a second time.
>
> It's the paragraph after "why would you need multiple handles for the
> same sending host?". The one which starts "Although actually..." and
> ends "...there's nothing in CSV which prevents that from working."

Thanks. Alright:

David Woodhouse wrote:
> [...]
> why would you need multiple handles for the same sending host?
>
> Although actually if the sender _really_ wants to, they _can_ give a
> different HELO name according to the mail they're sending. It's a bit
> pointless, but some people seem to do it anyway. And there's nothing in
> CSV which prevents that from working.

So you're saying it is up to the sending host to provide varying HELO
identities if the receiver is supposed to be able to discriminate mail
that originates from varying senders but is all sent through that common
host. I.e. they would say "HELO mehnle.net.mailout.isp.com".

Will they do that even for individual localparts (which SPF does support),
i.e., will they say "HELO julian._.mehnle.net.mailout.isp.com"?

That seems like a gross misuse of the HELO identity to me, plus I still
have to implement all the cryptographic SRS/BATV/SES stuff to actually
have MAIL FROM protected, plus I will still get (partial) SMTP
transactions for misdirected bounces (although I can abort them after
MAIL FROM), or at least I get all the incoming callbacks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHgAYDwL7PKlBZWjsRAgTrAKD8fnDhiSvxAWG3IcEaPyalQElhNwCfXDsb
2wvIaMV3G8vED3Vr0Ci7V5g=
=B2jm
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82237722-e114c3
Powered by Listbox: http://www.listbox.com

RE: Re: Revising SOFTFAIL [ In reply to ]

admin at asarian-host

Jan 5, 2008, 3:01 PM

Post #31 of 47 (13934 views)

Edmig wrote:

> Why do we care? If Y is reputable, and it says X is OK, we have

> what we need. If Z is forged, we tell Y, and they fire X.

> > It'd be a simple matter of granularity. In your example you can

> > either trust relay X completely, or not at all. A bit crude,

> > don't ya think?

> The granularity of the HELO name is controlled by the sender, as it

> should be.

I'm talking about the 'receiver' granularity of making a determination

based on HELO. And since the same relay will almost always use the same

HELO,'receiver' granularity is close to zilch in that scenario.

> If X can't get control of spammer accounts on its webmail servers, or

> whatever, it would be very easy for them to use a different HELO name

> for those servers.

In other words: let the legit relay determine what is spam, and let him

set a HELO accordingly? I'm afraid that doesn't make much sense. Other

than that you make spam-fighting an almost entirely passive operation that

way, having to rely on the goodwill and HELO of a legit relay who

allegedly already set a spam-HELO to indicate that the message to follow

will likely be spam, such a relay would be guilty of willingly sending out

spam in the first place. If you find a spammer on your server(s), you yank

his account, clear and simple; you don't let him send under a different

HELO. And if you're not the admin with sufficient privileges to remove his

account, then you notify someone who is. And if you ARE that admin, but

don't know how to remove the offending account anyway, then you notify

someone to remove you. :)

My ISP's servers (not my own) use a different strategy: they incorporate

the user account name in the HELO. Not even all that bad an idea, in terms

of helping receivers determine accountability. But it's a very rare thing;

and, for sendmail at least, I know it would require a customization of the

C source to get it to do that. So, I don't think we can really count on

such behaviors. The safest bet, way I see it, is to bank on the fact that

the HELO of the connecting client will not actively help you to make the

distinction between spammer and non-spammer (in terms of who uses his

relay), except in determining the overall status of whether said relay

itself is trustworthy or not. Hence, the lack of receiver granularity.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82242765-19ecc0
Powered by Listbox: http://www.listbox.com

RE: Re: Revising SOFTFAIL [ In reply to ]

admin at asarian-host

Jan 5, 2008, 3:01 PM

Post #32 of 47 (13938 views)

Edmig wrote:

> Why do we care? If Y is reputable, and it says X is OK, we have

> what we need. If Z is forged, we tell Y, and they fire X.

> > It'd be a simple matter of granularity. In your example you can

> > either trust relay X completely, or not at all. A bit crude,

> > don't ya think?

> The granularity of the HELO name is controlled by the sender, as it

> should be.

I'm talking about the 'receiver' granularity of making a determination

based on HELO. And since the same relay will almost always use the same

HELO,'receiver' granularity is close to zilch in that scenario.

> If X can't get control of spammer accounts on its webmail servers, or

> whatever, it would be very easy for them to use a different HELO name

> for those servers.

In other words: let the legit relay determine what is spam, and let him

set a HELO accordingly? I'm afraid that doesn't make much sense. Other

than that you make spam-fighting an almost entirely passive operation that

way, having to rely on the goodwill and HELO of a legit relay who

allegedly already set a spam-HELO to indicate that the message to follow

will likely be spam, such a relay would be guilty of willingly sending out

spam in the first place. If you find a spammer on your server(s), you yank

his account, clear and simple; you don't let him send under a different

HELO. And if you're not the admin with sufficient privileges to remove his

account, then you notify someone who is. And if you ARE that admin, but

don't know how to remove the offending account anyway, then you notify

someone to remove you. :)

My ISP's servers (not my own) use a different strategy: they incorporate

the user account name in the HELO. Not even all that bad an idea, in terms

of helping receivers determine accountability. But it's a very rare thing;

and, for sendmail at least, I know it would require a customization of the

C source to get it to do that. So, I don't think we can really count on

such behaviors. The safest bet, way I see it, is to bank on the fact that

the HELO of the connecting client will not actively help you to make the

distinction between spammer and non-spammer (in terms of who uses his

relay), except in determining the overall status of whether said relay

itself is trustworthy or not. Hence, the lack of receiver granularity.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82374312-98dd5a
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

dwmw2 at infradead

Jan 5, 2008, 3:05 PM

Post #33 of 47 (13959 views)

On Sat, 2008-01-05 at 22:34 +0000, Julian Mehnle wrote:
> David Woodhouse wrote:
> > [...]
> > why would you need multiple handles for the same sending host?
> >
> > Although actually if the sender _really_ wants to, they _can_ give a
> > different HELO name according to the mail they're sending. It's a bit
> > pointless, but some people seem to do it anyway. And there's nothing in
> > CSV which prevents that from working.
>
> So you're saying it is up to the sending host to provide varying HELO
> identities if the receiver is supposed to be able to discriminate mail
> that originates from varying senders but is all sent through that common
> host. I.e. they would say "HELO mehnle.net.mailout.isp.com".

Remember, we're talking about a 'handle' used to do lookups in some kind
of reputation system, which results in some answer like (for example):
"the domain woodhou.se sends mostly spam" or
"the host using HELO bombadil.infradead.org sends mostly ham".

If you're going to do that kind of lookup, you need some reliable way to
know that the mail you're receiving really _is_ associated with the
domain or host to which you're attributing it.

SPF attempts to provide that for domains, but makes not-entirely-true
assumptions about the way SMTP works in the real world. CSV provides it
for HELO names. Each just attempts to 'authenticate' the mail so that
you can reliably look up whatever 'handle' you've used.

So what I'm saying is that in the CSV case, if the admin of a sending
host _really_ wants to use multiple handles or 'reputations' -- perhaps
one for "definitely not spam, from customers who pay extra and whose
first-born we have in escrow", and another for "stuff which has SA
points, from Windows-using customers" -- they _could_ do that.

Some people providing mailservers have taken to using multiple servers
for outgoing mail -- a 'low-risk' server and a separate 'high-risk' one
which is more likely to get blacklisted. If the blacklisting were done
with a reputation database based on CSV, it would be theoretically
possible to do it on just one host, by using a different HELO name.

> Will they do that even for individual localparts (which SPF does support),
> i.e., will they say "HELO julian._.mehnle.net.mailout.isp.com"?

It would be theoretically possible for them to do so, although I find it
unlikely that many would. I'm not aware that SPF can do that. Of course
the localpart can be a factor in the calculation of the authentication
result, but I know of no way that you can force a recipient to make a
distinction between the reputation of 'foo@domain.com' and the
reputation of 'bar@domain.com' short of disowning one or the other.

--
dwmw2

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82244016-44dbcb
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

michael at talamasca

Jan 5, 2008, 3:56 PM

Post #34 of 47 (13936 views)

On Sat, 5 Jan 2008, David Woodhouse wrote:
> Remember, we're talking about a 'handle' used to do lookups in some kind
> [...]

I think I sort-of see what you're talking about. But two objections present
themselves.

First, CSV appears to be a Rube Goldberg contraption which basically does
what I already accomplish by first blocking mail where the sending IP has no
closed loop rDNS, and then running the confirmed hostname past a blacklist.
(Note I'm talking only talking about the rDNS hostname, not HELO.)

It does give the sender the advantage of running split reputations on a
single IP. But that's not in the interest of eradicating spam.

Second, it seems you're disparagement of SPF is based on the fact that SPF
blocks traditional forwarders from participating in the reputation system.

Reusing my example of <jane_roe@example.com> sending to
<john_doe@example.org> which forwards to <joe_smith@example.net>:

You are complaining that if traditional forwarding is used, example.net's
SPF implementation, aghast at what it sees as an attempt by example.org to
steal example.com's karma, unfairly denies example.org a chance to accumulate
karma of it's own. CSV would (but so would an IP or rDNS-based reputation
system.)

But this doesn't help example.org much, because the nature of forwarding
prevents it from maintaining good karma. Forwarders often have specific
direction as to what spam-filters to apply, so if Joe Smith specifies no
filtering and <john_doe@example.org> is on a "millions CD", then example.org
will see it's karma blacken due to spam that he effectively _demanded_ to
see.

example.org's only hope is for example.net to recognize it as a forwarder
blindly doing what Joe specified, and apply a whitelist. But if example.net
did whitelist example.org, it could also turn off SPF, and SPF's forwarder
problem would be no longer an issue.

So all reputation systems will mistreat forwarders in the absence of
whitelisting. CSV is not an improvement on SPF.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82281160-968c85
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

dwmw2 at infradead

Jan 6, 2008, 1:50 AM

Post #35 of 47 (13938 views)

On Sat, 2008-01-05 at 15:56 -0800, Michael Deutschmann wrote:
> You are complaining that if traditional forwarding is used, example.net's
> SPF implementation, aghast at what it sees as an attempt by example.org to
> steal example.com's karma, unfairly denies example.org a chance to accumulate
> karma of it's own.

No, I think you've missed the point somewhat -- that wasn't what I
object to at all.

--
dwmw2

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82353310-52c539
Powered by Listbox: http://www.listbox.com

Re: Revising SOFTFAIL [ In reply to ]

Jan 6, 2008, 3:52 AM

Post #36 of 47 (13921 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Woodhouse wrote:
> > Will they do that even for individual localparts (which SPF does
> > support), i.e., will they say
> > "HELO julian._.mehnle.net.mailout.isp.com"?
>
> It would be theoretically possible for them to do so, although I find
> it unlikely that many would. I'm not aware that SPF can do that.

If the sender enforces submission rights (RFC 4409, 6.1) and declares that
he is doing so by saying "op=auth" (draft-ellermann-spf-options, 3.4) in
their SPF record, you can take the localpart for granted.

http://tools.ietf.org/html/rfc4409#section-6.1
http://www.openspf.org/svn/project/specs/drafts/draft-ellermann-spf-options-01.txt

> Of course the localpart can be a factor in the calculation of the
> authentication result, but I know of no way that you can force a
> recipient to make a distinction between the reputation of
> 'foo@domain.com' and the reputation of 'bar@domain.com' short of
> disowning one or the other.

True, there's no way to force receivers. If they insist, they can always
choose to track reputation using only the coarsest granularity possible.
But it's always good to give them the _option_ to use a finer
granularity.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHgMD4wL7PKlBZWjsRAlqzAKCLRbE5SgSpijSqRi5hIUlwmn/qxwCfVvEl
BCcZt1ndymr+0IVllt4pa58=
=iAKz
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82355972-26b719
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

michael at talamasca

Jan 6, 2008, 4:36 AM

Post #37 of 47 (13924 views)

On Sun, 6 Jan 2008, you wrote:
> On Sat, 2008-01-05 at 15:56 -0800, Michael Deutschmann wrote:
> > You are complaining that if traditional forwarding is used, example.net's
> > SPF implementation, aghast at what it sees as an attempt by example.org to
> > steal example.com's karma, unfairly denies example.org a chance to accumulate
> > karma of it's own.
>
> No, I think you've missed the point somewhat -- that wasn't what I
> object to at all.

If not the "forwarding problem", then what else did you mean by
"not-entirely-true assumptions about the way SMTP works in the real
world"?

If you are thinking of the roaming user who doesn't change his MAIL FROM
as he connects his laptop to different ISPs, that's precisely what
Softfail and Neutral are intended for. Softfail is for ISPs who deprecate
the practice in favor of SMTP-AUTH, yet aren't confident that all users
are on board. Neutral is for ISPs that make no pretense that this
practice will end.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82357900-59803d
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

Jan 6, 2008, 9:59 AM

Post #38 of 47 (13922 views)

On Jan 6, 2008 4:52 AM, Julian Mehnle <julian@mehnle.net> wrote:

> David Woodhouse wrote:
>
> > Of course the localpart can be a factor in the calculation of the
> > authentication result, but I know of no way that you can force a
> > recipient to make a distinction between the reputation of
> > 'foo@domain.com' and the reputation of 'bar@domain.com' short of
> > disowning one or the other.
>
> True, there's no way to force receivers. If they insist, they can always
> choose to track reputation using only the coarsest granularity possible.
> But it's always good to give them the _option_ to use a finer
> granularity.

I would say the option should go the other way. A receiver shouldn't chose
*finer* granularity than what is specified by the sender, but under some
circumstances might want to chose *coarser* granularity.

"Granularity" if I understand the meaning as applied to domain names above,
should be chosen by the party most familiar with the situation at the source
- which accounts can be trusted, etc. Legitimate enders will want course
granularity to maintain a large flow with a good reputation, and fine
granularity to isolate flows with bad reputations. Spammers will want the
finest granularity possible - a new name for each session.

As applied to domain names, it might make sense for a receiver to *enlarge*
the granularity chosen by the sender, if for example, the sender wants one
IP per grain, and the receiver can see a block of IPs with a consistent
pattern of abuse.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82390401-06c87f
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

Jan 6, 2008, 10:16 AM

Post #39 of 47 (13906 views)

On Jan 5, 2008 4:01 PM, Mark <admin@asarian-host.net> wrote:

> Edmig wrote:
> > If X can't get control of spammer accounts on its webmail servers, or
>
> > whatever, it would be very easy for them to use a different HELO name
>
> > for those servers.
>

> In other words: let the legit relay determine what is spam, and let him
>
> set a HELO accordingly? I'm afraid that doesn't make much sense. Other
>
> than that you make spam-fighting an almost entirely passive operation that
>
> way, having to rely on the goodwill and HELO of a legit relay who
>
What is the purpose of a relay, other than to ensure the deliverability of
its clients' messages? This is where the burden of stopping spam belongs,
and where it can be done most easily. The relay knows (or certainly should
know) the clients for which it is handling mail.

> allegedly already set a spam-HELO to indicate that the message to follow
>
> will likely be spam, such a relay would be guilty of willingly sending out
>
> spam in the first place.
>
No legitimate relay would send messages *likely* to be spam. A more
realistic case is a relay handling both individual messages and mailing
lists.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82393857-9e290d
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

Jan 6, 2008, 10:25 AM

Post #40 of 47 (13921 views)

On Jan 5, 2008 10:08 AM, Alex van den Bogaerdt <alex@ergens.op.het.net>
wrote:

> > There is *no* simple rule which says that a sending host's name
> > > has to match the sender's email address.
> >
> > But it does have to correlate with the IP address used by the sending
> host.
> > Which raises the question again - why not just use the HELO name to
> > authenticate an incoming IP address?
>
> uplink-01-xyz.somecarrier.example. A 10.1.2.3
> ge5-3-2.othercarrier.example. A 172.16.1.2
> mailhost.provider.example. A 192.168.1.1
> internal.provider.example. A 192.168.2.1
> external.provider.example . A 192.168.3.1
>
> Which of these names is *the* fully qualified principle hostname?

It doesn't matter.

>
> Which of these addresses is connecting to your mailhost?

There is only one source address in a TCP connection, and it can't be
forged.

What matters is that a domain owner is willing to assume responsibility for
that address.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82396273-4e29cb
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

scott at kitterman

Jan 6, 2008, 11:25 AM

Post #41 of 47 (13924 views)

On Sun, 6 Jan 2008 10:59:56 -0700 Edmig <emgemgemg@gmail.com> wrote:
>On Jan 6, 2008 4:52 AM, Julian Mehnle <julian@mehnle.net> wrote:
>
>> David Woodhouse wrote:
>>
>> > Of course the localpart can be a factor in the calculation of the
>> > authentication result, but I know of no way that you can force a
>> > recipient to make a distinction between the reputation of
>> > 'foo@domain.com' and the reputation of 'bar@domain.com' short of
>> > disowning one or the other.
>>
>> True, there's no way to force receivers. If they insist, they can always
>> choose to track reputation using only the coarsest granularity possible.
>> But it's always good to give them the _option_ to use a finer
>> granularity.
>
>
>I would say the option should go the other way. A receiver shouldn't chose
>*finer* granularity than what is specified by the sender, but under some
>circumstances might want to chose *coarser* granularity.
>
>"Granularity" if I understand the meaning as applied to domain names above,
>should be chosen by the party most familiar with the situation at the
source
>- which accounts can be trusted, etc. Legitimate enders will want course
>granularity to maintain a large flow with a good reputation, and fine
>granularity to isolate flows with bad reputations. Spammers will want the
>finest granularity possible - a new name for each session.
>
>As applied to domain names, it might make sense for a receiver to *enlarge*
>the granularity chosen by the sender, if for example, the sender wants one
>IP per grain, and the receiver can see a block of IPs with a consistent
>pattern of abuse.
>

No receiver is going to be bound by what a sender wants. There are limited
circumstancew where what the sender wants may be an input in what the
receiver decides to do, but that's it.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82415156-84053e
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

scott at kitterman

Jan 6, 2008, 11:36 AM

Post #42 of 47 (13917 views)

On Sun, 6 Jan 2008 11:16:56 -0700 Edmig <emgemgemg@gmail.com> wrote:
>On Jan 5, 2008 4:01 PM, Mark <admin@asarian-host.net> wrote:
>
>> Edmig wrote:
>> > If X can't get control of spammer accounts on its webmail servers, or
>>
>> > whatever, it would be very easy for them to use a different HELO name
>>
>> > for those servers.
>>
>
>
>> In other words: let the legit relay determine what is spam, and let him
>>
>> set a HELO accordingly? I'm afraid that doesn't make much sense. Other
>>
>> than that you make spam-fighting an almost entirely passive operation
that
>>
>> way, having to rely on the goodwill and HELO of a legit relay who
>>
>What is the purpose of a relay, other than to ensure the deliverability of
>its clients' messages? This is where the burden of stopping spam belongs,
>and where it can be done most easily. The relay knows (or certainly should
>know) the clients for which it is handling mail.
>
>> allegedly already set a spam-HELO to indicate that the message to follow
>>
>> will likely be spam, such a relay would be guilty of willingly sending
out
>>
>> spam in the first place.
>>
>No legitimate relay would send messages *likely* to be spam. A more
>realistic case is a relay handling both individual messages and mailing
>lists.

They may not have a choice. Once mail has been accepted by the relay they
pretty much have deliver it (possibly tagged as spam). Having mail vanish
into a black hole at a relay is a recipe for unreliability.

For reasons of performance and scalability most content based scanning is
done after mail has already been accepted and queued.

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82416431-04accb
Powered by Listbox: http://www.listbox.com

RE: Re: Revising SOFTFAIL [ In reply to ]

admin at asarian-host

Jan 6, 2008, 12:52 PM

Post #43 of 47 (13922 views)

From: Edmig [mailto:emgemgemg@gmail.com]

Sent: zondag 6 januari 2008 19:17

To: spf-discuss@v2.listbox.com

Subject: Re: [spf-discuss] Re: Revising SOFTFAIL

> > On Jan 5, 2008 4:01 PM, Mark <admin@asarian-host.net> wrote:

> >

> > In other words: let the legit relay determine what is spam, and let him

> > set a HELO accordingly? I'm afraid that doesn't make much sense. Other

> > than that you make spam-fighting an almost entirely passive operation

> > that way, having to rely on the goodwill and HELO of a legit relay...

>

> What is the purpose of a relay, other than to ensure the deliverability

> of its clients' messages? This is where the burden of stopping spam

> belongs, and where it can be done most easily.

There's a difference between hoping the relay will have checked for spam,

and counting on it. I'm saying: don't count on it. As receiving MTA, it

sure were nice if I could count on the last hop having set a nice, special

HELO for me, to indicate it didn't quite trust the sender or his mail. But

is that a realistic scenario? I don't think so. And even if someone

actually did that, as receiver I cannot bank on others doing my (partial)

homework for me. I am, as it were, purposely not 'cognizant', to use a

legal term, of what the connecting client may or may not have added in the

department of extra info that might help me determine whether a message is

a likely spam.

Also, what you suggested, that such info could be send along, as it were,

by means of different HELO, is not currently done a lot (if at all).

Likely they added some SpamAssassin headers or so, if they did any

checking at all. But I can't be bothered trying to come up with difficult

schemes to determine the validity of said headers (as if there even were

such a reliable method); and even if those headers were real, the spammer

could have just added those himself.

In short, far as I'm concerned, I rely on my own mettle.

- Mark

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82427782-a42378
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

dotzero at gmail

Jan 7, 2008, 6:19 AM

Post #44 of 47 (13923 views)

On 1/6/08, Edmig <emgemgemg@gmail.com> wrote:
>
>
>
> >
> > Which of these addresses is connecting to your mailhost?
>
>
> There is only one source address in a TCP connection, and it can't be
> forged.
>
> What matters is that a domain owner is willing to assume responsibility
> for that address.
>

I love it when someone makes a delcarative statement that is incorrect. As I
read what you wrote I immediately thought of a case even before reading your
next sentence.

When an IP address is on the same subnet (collision domain) as another, it
is certainly possible to forge the source IP address. Now most people would
think of that in an RFC1918 context. But what about small
companies/organizations that are assigned external IPs by their upstream.
Food for thought.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82575913-6b9784
Powered by Listbox: http://www.listbox.com

Re: Revising SOFTFAIL [ In reply to ]

Jan 7, 2008, 6:29 AM

Post #45 of 47 (13924 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dotzero wrote:
> On 1/6/08, Edmig <emgemgemg@gmail.com> wrote:
> > > Which of these addresses is connecting to your mailhost?
> >
> > There is only one source address in a TCP connection, and it can't be
> > forged.
> >
> > What matters is that a domain owner is willing to assume
> > responsibility for that address.
>
> I love it when someone makes a delcarative statement that is incorrect.
> As I read what you wrote I immediately thought of a case even before
> reading your next sentence.
>
> When an IP address is on the same subnet (collision domain) as another,
> it is certainly possible to forge the source IP address. Now most
> people would think of that in an RFC1918 context. But what about small
> companies/organizations that are assigned external IPs by their
> upstream. Food for thought.

Then they cannot talk SMTP to the outside Internet directly because TCP
return packets will be routed to where those IP addresses are
_officially_ allocated. Thus this is of no concern to MTAs receiving
inbound SMTP connections.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHgjcywL7PKlBZWjsRAqPXAKDjgeH9hAy0tJulFWl6rHI6hZZujwCglPF6
h/uOE5Rmqz/ygo10Uk4V+Fw=
=NDva
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82581423-08d586
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

dotzero at gmail

Jan 7, 2008, 7:01 AM

Post #46 of 47 (13929 views)

On 1/7/08, Julian Mehnle <julian@mehnle.net> wrote:
>
> Then they cannot talk SMTP to the outside Internet directly because TCP
> return packets will be routed to where those IP addresses are
> _officially_ allocated. Thus this is of no concern to MTAs receiving
> inbound SMTP connections.
>

Sure about that?

What about ARP poisoning attacks. Remember, I stipulated that the IP
addresses are on the same external subnet/collision domain. In that
case the MAC address is used, not the IP address. There are ways to
address this (port lockdown for example) but it isn't always done.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=82601362-33dbd4
Powered by Listbox: http://www.listbox.com

Re: Re: Revising SOFTFAIL [ In reply to ]

Jan 7, 2008, 10:20 AM

Post #47 of 47 (13934 views)