Mailing List Archive

My view is that there is no one solution to the 'forwarding problem'.

We need a suite of solutions that meets different needs. SRS is A solution,
not THE solution.

Forwarder whitelisting is definitely needed.

I'm not sure that trusted-forwarder.org should ever go away.

SES/BATV/SRS-0 in combinations with exists may be a solution.

Personally I published a -all record understanding that forwarded messages may
get rejected. When it happens (two messages in 2 1/2 years) I just resend
them.

I agree that this is an area we need to work on. One of the reasons I
recently started a separate Postfix policy daemon for SPF (see
http://www.openspf.org/Software - it's the Python one I'm talking about) is
that I want a vehicle to prototype forwarder whitelisting. I've got other
stuff I need to do with it before I get to that, but that's one of the things
on my list.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Jan 25, 2007, at 9:42 PM, Scott Kitterman wrote:

>
> Forwarder whitelisting is definitely needed.

If folks want a place to cooperatively whitelist forwarders, I'll
have one ready soon .... folks can start by building a list of IP
addresses, hostnames, etc, and then I will aggregate those lists and
munge them together into a big whitelist.



-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thu, 25 Jan 2007, Meng Weng Wong wrote:

> On Jan 25, 2007, at 9:42 PM, Scott Kitterman wrote:
>>
>> Forwarder whitelisting is definitely needed.
>
> If folks want a place to cooperatively whitelist forwarders, I'll have one
> ready soon .... folks can start by building a list of IP addresses,
> hostnames, etc, and then I will aggregate those lists and munge them
> together into a big whitelist.

You mean like "trusted-forwarders.org" but larger?

The issue I see is that number of systems doing only forwarding
or similar like pobox is rather low. What we really have is
large number of ISP mail servers (and univerisities and some
corporate mail servers though last one is less common) that
normally just process incoming/outgoing email for the company
but on occasion would do inline forwarding using aliases file
(sometimes quite large pre-build from internal db).

So what you end up building is list of known mail servers in
general which can get quite large and somewhat difficult to
maintain and be accurate long-term.

--
William Leibzon
Elan Networks
william@elan.net

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thu, 25 Jan 2007, william(at)elan.net wrote:

>>> Forwarder whitelisting is definitely needed.
>>
>> If folks want a place to cooperatively whitelist forwarders, I'll have one
>> ready soon .... folks can start by building a list of IP addresses,
>> hostnames, etc, and then I will aggregate those lists and munge them
>> together into a big whitelist.
>
> You mean like "trusted-forwarders.org" but larger?
>
> The issue I see is that number of systems doing only forwarding
> or similar like pobox is rather low. What we really have is
> large number of ISP mail servers (and univerisities and some
> corporate mail servers though last one is less common) that

What I forgot to include are bunch of personal boxes many of
of us run for friends and family and that often have many
aliases setup. Plus to that many domain registrars (like enom)
allow to setup email forwarding, though those can probably be
considered forwarding services in the same way as pobox.

--
William Leibzon
Elan Networks
william@elan.net

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Michael Deutschmann wrote:

> An attitude I'd like to see stopped is the position that since
> SRS patches now exist for most MTAs, administrators should
> ignore the forwarding problem and just enable receiverside SPF
> checking blindly.

SRS isn't the only available strategy, but otherwise I favour
"just reject SPF FAIL, blindly or otherwise". An occasional
pseudo-551 (= user not local) bounce is no big issue from my
POV as sender with a PASS / FAIL policy.

> most recipients will "break" and demand receiverside SPF be
> turned off before forwarders "break" and do SRS.

That's about receivers with a broken forwarding arrangement.

For various reasons (not only SPF) forwarding is an unpopular
service, and a common way to get a similar effect is to use
auto-POP3-polling.

> this attitude will inspire some senders to unnecessarily
> (from our POV) use "?all" in their senderside SPF to ensure
> that their mail will go through

Yes, that's the old "SPF FAIL is not for cowards" attitude.
IMO it's okay if some publishers focus on getting PASS right.

It won't help them to eliminate forgeries, but at least they
get a PASS for almost all receivers - minus the few using a
legacy forwarder before the SPF check.

> we need to accept that, for now, receiverside SPF can only
> be deployed by and for mail experts who can identify and
> whitelist all traditional forwarders.

IBTD.

> Any reaction from the candidates to this position?

If somebody feels like it, Meng's old SRS draft is really old,
an update could make sense. The BATV folks recently revived
their old draft, maybe the SES fans are now up to the task to
publish their concept as ASCII plain/text.

But actually I think that SES is dead, all that's left is a
moving target claiming to be the better DKIM while talking
about DKIM, claiming to be the original BATV while talking
about BATV, and claiming to be better than SRS while talking
about SRS.

Which might be all true, but then it's not one "SES", but a
set of very different SES-variants, with no specification
to speak of at all. For a recent summary of my thoughts see
also news://news.spamcop.net/45B2AA76.7F9A@xyzzy.claranet.de

I think that the 2821bis WG Charter debate [1,2] is the most
important issue at this time. If the planned WG is bound to
keep ESMTP as is, then mail as we know it is doomed.

Frank

1: http://permalink.gmane.org/gmane.ietf.smtp/5178
2: http://permalink.gmane.org/gmane.ietf.smtp/5180


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Meng Weng Wong wrote:

> I will aggregate those lists and munge them together into a big whitelist.

Is that something like a centralized "SPF HELO best guess" white list,
like Wayne's "trusted forwarder" list ? For a receiver it would be
interesting to know if the forwarders at least guarantee to reject an
SPF FAIL at their border.

The SenderID users might be interested to know if a genuine PRA FAIL
is rejected by these legacy forwarders, and if they support RFC 4405.
Has anybody implemented RFC 4405 (= responsible submitter) so far, or
can we ignore it as stillborn ?

If a legacy forwarder doesn't reject SPF FAIL, then it most likely
also has no clue about publishing SPF HELO policies for its MTAs,
and the very last chance to get anythng right would be to take the
responsibility for its dubious practise by a DKIM-signature.

If that also fails I don't see the purpose of "white listing" such
clueless and greedy forwarders. "It's not my spam, it's not my
problem, I only forwarded it", this simply _cannot_ work, even if
some receivers wish that it _should_ work.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thu, 25 Jan 2007, I wrote:
> Well, about time I voted...
>
> The reason I bothered registering is that I see one area where the SPF
> effort could be guided better. This is the forwarding problem.
>
> [...]
>
> Any reaction from the candidates to this position?

So far I've seen two responses, one from Kitterman that was
sortof-positive, and one from Ellerman that was sortof-negative.

I thought of a simpler way to seperate people who are on my wavelength
from those who are not:

All of you, I understand, are promising to proselytize SPF deployment as
much as possible.

What I'm looking for is an understanding that, while senderside SPF
deployment can and should be encouraged with full force, we need to take
it slow on the receiverside to avoid problems of the sort Per Jessen
just walked in with.

Basically, I think we should consider it a receiverside "victory" when an
ISP is adding Received-SPF: headers, and offering a reject-on-SPF-fail
policy on a per-mailbox *opt-in* basis. When an ISP deploys "armed"
receiverside SPF as the default policy, that isn't a victory -- in fact
it's a dangerous situation that we should avoid leading people into.

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

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Thursday 25 January 2007 23:50, Michael Deutschmann wrote:
...
> An attitude I'd like to see stopped is the position that since SRS patches
> now exist for most MTAs, administrators should ignore the forwarding
> problem and just enable receiverside SPF checking blindly. Such
> brinksmanship might be the only way to drive significant SRS uptake, but I
> believe that will in fact hurt us.

I should have also added that I think that while 3rd party patching of MTAs
directly for experimental purposes is a fine idea, it's not suitable for a
long term solution to any software problem. I don't think we have SRS
support in an MTA until the patch has been incoporated in the MTA's source or
SRS can be supported through a publically defined/supported interface. By
that measure I'm not sure any MTAs suitably support SRS (Sendmail is
possibly/probably the lone exception - I know milters doing SRS have to use a
non-milter API call to change mail from, but not if they are using a public
or private interface to do it).


Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Friday 26 January 2007 02:55, william(at)elan.net wrote:

> What I forgot to include are bunch of personal boxes many of
> of us run for friends and family and that often have many
> aliases setup.

I did that for my father (who uses AOL) until AOL blacklisted my server IP for
relaying spam to them. This in a nutshell is why I think alias forwarding is
doomed in the long run (but the long run isn't here yet and we have to manage
in the meantime).

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Fri, 26 Jan 2007, Michael Deutschmann wrote:

> So far I've seen two responses, one from Kitterman that was
> sortof-positive, and one from Ellerman that was sortof-negative.

My comments on SRS are on the FAQ:

http://www.openspf.org/Best_Practices/Forwarding

However, I have 4 systems running the pygossip reputation system now,
and I'm seeing another side of forwarding.

Reputation systems assign blame for spam. Without SPF, blame is assigned
by IP, like AOL does. With SPF, blame is assigned by domain for
SPF pass. [*] Forwarding without SRS is essentially "without SPF".

Either way, forwarding puts your (the forwarders) reputation at risk.
If the receiver does not whitelist you, any spam you forward to them
counts against your reputation. As reputation systems become more
prevalent, forwarders will need to demand whitelisting from recipients.
This is already happening with AOL. Google for AOL forwarding, and
you'll see that mailing list managers (a similar reputation problem
to forwarding) find themselves either:

a) banning aol.com recipients from the mailing list
b) using VERP to immediately unsubscribe any recipient reporting
a list message as spam.

Failure to take either of the above steps allows any clueless or malicious
AOL user (ok, likely the former) to DOS every mailing list hosted on that
IP for all AOL users.

The bottom line is that email reputation makes forwarding email something
like cosigning a loan. Your email reputation is at the mercy of the
recipient as long as the forward is active. In light of this, it is
in the best interest of forwarders to:

a) demand whitelisting from recipients
b) put technical measures in place to monitor demerits against your IP/domain
c) put technical measures in place to trace which recipient is responsible for
any spam reports against your domain, and disable their forwarding to
protect service for your other recipients/customers.

The choice of SRS for forwards is essentially a choice of whether they
want to risk their domain reputation (SRS) or their IP reputation (no SRS)
for forwarded mail. It makes sense, actually, to risk only IP reputation
(no SRS) for forwarding so as to be able to assign a new IP from a block
in case of abuse by a recipient that results in DOS.

The other unexpected (to me) issue to come out of this is that reputation
systems need to hold recipients accountable. Any system that blocks
email based on recipient reports of "spam" needs some way to hold
said recipient accountable - otherwise one clueless or evil user can
DOS an entire community (hi AOL).

[*] For other SPF results (besides fail), blame could be assigned by
IP, by domain, or by a combination. I've experimented with the
following (format is reputationid:qualifier):

example.com:neutral
1.2.3.4:IP
example.com:1.2.3.4

The last, assign reputation to the combination of domain and IP, is
the most "fair". But it gives too much advantage to spammers. The
next step is accruing reputation to IP like AOL. This is better, but
thanks to botnets, you have to be AOL to actually get around to blacklisting
any IPs. Each bot sends you only about 5 spams before moving on.

For small fry like myself, example.com:neutral or example.com:softfail
starts blacklisting much faster. Any upgrade in SPF policy resets
a domains reputation (for potentially legit mail).

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

At 02:05 PM 1/26/2007 -0500, Stuart Gathman wrote:

>Either way, forwarding puts your (the forwarders) reputation at risk.
>If the receiver does not whitelist you, any spam you forward to them
>counts against your reputation. As reputation systems become more
>prevalent, forwarders will need to demand whitelisting from recipients.
>This is already happening with AOL. Google for AOL forwarding, and
>you'll see that mailing list managers (a similar reputation problem
>to forwarding) find themselves either:
>
>a) banning aol.com recipients from the mailing list
>b) using VERP to immediately unsubscribe any recipient reporting
> a list message as spam.
>
>Failure to take either of the above steps allows any clueless or malicious
>AOL user (ok, likely the former) to DOS every mailing list hosted on that
>IP for all AOL users.

I've had similar problems with Yahoo labeling as spam anything we forwarded
to one of our yahoo.com recipients. They now have us on their whitelist,
but it took a lot of effort for just one ESP. I wonder if a more efficient
way to communicate with such companies would be to refer our clients having
such problems to a published list of "Reputable Email Service
Providers". If even half of these clients switched to another service,
that might be sufficient incentive for an ESP to streamline its
whitelisting procedures, and get on the list.

I know these big companies like to minimize their support costs by offering
their clients very few choices or options, but this could be done without
any client interaction. If an AOL subscriber reports his own forwarder as
a spammer, AOL should recognize that as a unique situation, and give the
forwarder a reasonable time to remove that subscriber. Seems like this is
not too much different than a legitimate mailing list getting an invalid
spam report.

Is anyone interested in helping me compile such a list?

-- Dave


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Michael Deutschmann wrote:
> Well, about time I voted...
>
> The reason I bothered registering is that I see one area where the SPF
> effort could be guided better. This is the forwarding problem.
>
> [...]
>
> Any reaction from the candidates to this position?

I think SRS is a hack that isn't likely to get deployed widely any time
soon -- probably not even in the long run. Instead I think that the net
should conceptually be divided into exactly two halves at all times: the
sender's network and the receiver's network. There is no room for
unaccountable middlemen "just passing mail along". If I as a receiver set
up a forwarding using a 3rd party's forwarding service, I will have to
trust them and consider them part of my own e-mail network. That's
essentially what the lame "TENBOX" catchphrase is about. (Can we find
another term? In any case I think we do need one.)

One other idea that has been buried in RFCs 821 and 2821 largely unnoticed
is the HTTP-redirection-like "551 User not local; please try <joe@example.
org>"-style "forwarding" (Frank mentioned it before). I think this would
be _the_ solution if only more MTAs supported it. If we want to work on
getting rid of the forwarding problem in _MTAs_ (as opposed to writing
glue code for receiver-side forwarder white-listing), that's where we
should channel our efforts.

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

iD8DBQFFurIswL7PKlBZWjsRAsyAAKCi8KQAxTIJBUZWCaS7T6UDBkObWwCdHeWa
o4j8ETzmsyFOqQ91wEMof2U=
=QioH
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Meng Weng Wong wrote:
> On Jan 25, 2007, at 9:42 PM, Scott Kitterman wrote:
> > Forwarder whitelisting is definitely needed.
>
> If folks want a place to cooperatively whitelist forwarders, I'll
> have one ready soon .... folks can start by building a list of IP
> addresses, hostnames, etc, and then I will aggregate those lists and
> munge them together into a big whitelist.

The problem with that is that trust shouldn't be centralized (i.e.
delegated) blindly. Who is a trustworthy forwarder is a matter of
perspective, which is why trusted-forwarder.org is _right_ to go away in
the mid-term.

However, I won't start bitching about services and concepts that I haven't
seen yet, so I'll let you take me by surprise. :-)

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

iD8DBQFFurMxwL7PKlBZWjsRAv5pAKDtNxBBVqUA1yzGOCgdYASGNYQeJACeJV8B
D0/ThbkpcZA0J3QHCj+7omw=
=hQKT
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

David MacQuigg wrote:
> Is anyone interested in helping me compile such a list [of "Reputable
> Email Service Providers"]?

In order to be fair, such a list requires some formal criteria. Can you
suggest some?

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

iD8DBQFFurOpwL7PKlBZWjsRAiwFAJ9ozPCE8juCFapBogtRjp8T0XMqlACg7WH+
v7nMqNVoEUku/uyC+eZGrjk=
=rGvZ
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

At 02:06 AM 1/27/2007 +0000, Julian Mehnle wrote:
>David MacQuigg wrote:
> > Is anyone interested in helping me compile such a list [of "Reputable
> > Email Service Providers"]?
>
>In order to be fair, such a list requires some formal criteria. Can you
>suggest some?

- not rejecting or labeling as spam, mail from a domain that the recipient
would like "whitelisted".

I guess we should make the list one of "Reputable and Competent Email
Service Providers", since competence is the issue when we are discussing
problems on the receiver's side.

It occurs to me that it would be much easier to maintain a list of the few
large services (and spam appliances) that have problems, not the vast
majority that don't. This will also allow us to publish a short statement
of exactly what the problem is with a particular service. Here is a start:

aol.com - see earlier discussion

yahoo.com - offers blacklisting, but no option for recipients to whitelist
a sender. The sender is expected to register with Yahoo as a Mailing List,
and this is a difficult process, especially for forwarders and other
senders who are not mailing lists.

Any others? Please be specific.

Most small companies now use a spam appliance, like the Barracuda box we
have at U of A. These seem to be very "user friendly" in providing a nice
web interface for whitelisting and blacklisting.

-- Dave


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sat, 27 Jan 2007, David MacQuigg wrote:

> Most small companies now use a spam appliance, like the Barracuda box we
> have at U of A. These seem to be very "user friendly" in providing a nice
> web interface for whitelisting and blacklisting.

I get a constant stream of spam from barracudas. Like this, only several
times a minute:

2007Jan27 00:57:29 [399] connect from navgw2.affinitygroup.com at ('12.17.223.118', 41374) EXTERNAL
2007Jan27 00:57:29 [399] hello from den-barracuda.affinitygroup.com
2007Jan27 00:57:29 [399] mail from <> ('SIZE=2516',)
2007Jan27 00:57:29 [399] Received-SPF: none (mail.bmsi.com: 12.17.223.118 is neither permitted nor denied by domain of den-barracuda.affinitygroup.com) client_ip=12.17.223.118; helo=den-barracuda.affinitygroup.com; receiver=mail.bmsi.com; identity=helo
2007Jan27 00:57:29 [399] X-Guessed-SPF: neutral
2007Jan27 00:57:29 [399] rcpt to <rkmna@bmsaix.bmsi.com> ()
2007Jan27 00:57:29 [399] REJECT: bounce with no SRS encoding

The only good thing is that they have *finally* started using real
DSNs instead of replies, so at least I am rejecting them in SMTP
envelope now. I would actually be impressed if they checked SPF and
rejected SPF FAIL. (Although maybe that is a config option, and I
just never see mail from boxes that are configured that way.)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

At 12:13 PM 1/27/2007 -0500, you wrote:

>On Sat, 27 Jan 2007, David MacQuigg wrote:
>
> > Most small companies now use a spam appliance, like the Barracuda box we
> > have at U of A. These seem to be very "user friendly" in providing a nice
> > web interface for whitelisting and blacklisting.
>
>I get a constant stream of spam from barracudas. Like this, only several
>times a minute:
>
>2007Jan27 00:57:29 [399] connect from navgw2.affinitygroup.com at
>('12.17.223.118', 41374) EXTERNAL
>2007Jan27 00:57:29 [399] hello from den-barracuda.affinitygroup.com
>2007Jan27 00:57:29 [399] mail from <> ('SIZE=2516',)
>2007Jan27 00:57:29 [399] Received-SPF: none (mail.bmsi.com: 12.17.223.118
>is neither permitted nor denied by domain of
>den-barracuda.affinitygroup.com) client_ip=12.17.223.118;
>helo=den-barracuda.affinitygroup.com; receiver=mail.bmsi.com; identity=helo
>2007Jan27 00:57:29 [399] X-Guessed-SPF: neutral
>2007Jan27 00:57:29 [399] rcpt to <rkmna@bmsaix.bmsi.com> ()
>2007Jan27 00:57:29 [399] REJECT: bounce with no SRS encoding
>
>The only good thing is that they have *finally* started using real
>DSNs instead of replies, so at least I am rejecting them in SMTP
>envelope now. I would actually be impressed if they checked SPF and
>rejected SPF FAIL. (Although maybe that is a config option, and I
>just never see mail from boxes that are configured that way.)

OK, this is excellent input for my list of services with mail-handling
problems. I wasn't aware of this, probably because my domains are too
small for spammers to use as forged return addresses, and I'm only on the
recipient side of this firewall.

Barracuda Spam Firewall - sends "bounce spam" to forged return
addresses. This can get your IP blacklisted.

Have I summarized this correctly? I'll keep your post above in my file, in
case anyone asks for specifics on why Barracuda is listed as having problems.

Any more candidates - either spam appliances or email services that the
public might subscribe to?

-- Dave


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

David MacQuigg wrote:

> Barracuda Spam Firewall - sends "bounce spam" to forged
> return addresses. This can get your IP blacklisted.

> Have I summarized this correctly?

Yes. But it's old (2004) news, at this time it was the
default behaviour of "barracudas", admins had to fix it.

I'd be surprised if it's still the default behaviour for
new "barracudas". But maybe admins can now screw it up.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sat, 27 Jan 2007, Julian Mehnle wrote:
> That's essentially what the lame "TENBOX" catchphrase is about. (Can we
> find another term? In any case I think we do need one.)

That reminds me -- you never responded to my suggestion that the TENBOX
requirements should be split into two. There should be a TENBOX
Authentication protocol that forwarders to mark their forwards with a
forgery-proof token the recipient can whitelist, and a TENBOX
Authorization protocol that allows a forwarder to request whitelisting
from the recipient MTA with no more enduser involvement than subscribing
to a mailing list.

If you want new acronyms, how about:

FAR - Forwarding Agent Recognition

for the authentication protocol, and

FAME - Forwarder Authorization Made Easy

for the authorization end.

> One other idea that has been buried in RFCs 821 and 2821 largely unnoticed
> is the HTTP-redirection-like "551 User not local; please try <joe@example.
> org>"-style "forwarding" (Frank mentioned it before). I think this would
> be _the_ solution if only more MTAs supported it. If we want to work on

Problem is that most uses of forwarding are accounted by:

* People who want to send and recieve mail under a pseudonym.

* People who don't expect much of the spam defenses at their real address,
so they use a forwarding service with better defences as their only
world-visible address.

* People who are using mail aliases as canary traps to detect misuse of
e-mails collected by businesses.

In all these cases, disclosure of the direct address to all and sundry,
which is what 551 implies, would defeat the whole purpose of the forwarding.

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

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Michael Deutschmann wrote:
> On Sat, 27 Jan 2007, Julian Mehnle wrote:
> > That's essentially what the lame "TENBOX" catchphrase is about. (Can
> > we find another term? In any case I think we do need one.)
>
> That reminds me -- you never responded to my suggestion that the TENBOX
> requirements should be split into two.

(That's because I seem to have missed it. Can you point me to the message
where you originally made that suggestion?)

> There should be a TENBOX Authentication protocol that forwarders to mark
> their forwards with a forgery-proof token the recipient can whitelist,
> and a TENBOX Authorization protocol that allows a forwarder to request
> whitelisting from the recipient MTA with no more enduser involvement than
> subscribing to a mailing list.

When you say "mark forwards with a forgery-proof token the recipient can
whitelist", do you really mean some kind of mark that gets applied to
every message during forwarding? I don't think that would fly. If it
flied, we'd have a solution equivalent to DKIM or PGP. That could work
but would be significantly more effort than simply semi-statically white-
listing forwarders by their IP addresses.

Perhaps a prototype implementation is in order...

> If you want new acronyms, how about:
>
> FAR - Forwarding Agent Recognition
>
> for the authentication protocol, and
>
> FAME - Forwarder Authorization Made Easy
>
> for the authorization end.

About choosing new acronyms... I think we should stay with "TENBOX" during
the concept phase, as that's the term under which related discussion can
be found in the mailing list archives. But it is not a good term for a
technical/pubilicity "end product". We need a new term (or terms) for
that.

> > One other idea that has been buried in RFCs 821 and 2821 largely
> > unnoticed is the HTTP-redirection-like "551 User not local; please try
> > <joe@example. org>"-style "forwarding" (Frank mentioned it before). I
> > think this would be _the_ solution if only more MTAs supported it. If
> > we want to work on
>
> Problem is that most uses of forwarding are accounted by:
> [see enumeration of cases below]
> In all these cases, disclosure of the direct address to all and sundry,
> which is what 551 implies, would defeat the whole purpose of the
> forwarding.

There are still cases where redirection-style "forwarding" is acceptable.
For those cases, redirection forwarding is a simple solution. For all the
other cases, alias forwarding simply won't cut it without forwarder
white-listing.

> * People who want to send and recieve mail under a pseudonym.

Legitimate case.

> * People who don't expect much of the spam defenses at their real
> address, so they use a forwarding service with better defences as their
> only world-visible address.

Legitimate case, but also a textbook example of when the receiver should
consider the forwarder to be part of their e-mail infrastructure (and thus
white-list the forwarder from SPF and perhaps most other checks).

> * People who are using mail aliases as canary traps to detect misuse of
> e-mails collected by businesses.

You don't have to use a forwarding service to set up disposable addresses.
(Of course your immediate ESP may not support it, but that's not a
_fundamental_ problem that requires a forwarding service.)

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

iD8DBQFFvSNvwL7PKlBZWjsRAkqbAJ9suUeJAQc3YAkW8toB/xMuetKfQwCgigpo
pOBCzOzsI4ovGPj8Ln2D0Gw=
=3XIX
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sun, 28 Jan 2007, you wrote:
> (That's because I seem to have missed it. Can you point me to the message
> where you originally made that suggestion?)

It's:

Date: Mon, 15 Jan 2007 16:45:16 -0800 (PST)
From: Michael Deutschmann <michael@talamasca.ocis.net>
Subject: Re: [spf-discuss] Re: The forwarder's perspective
Message-ID: <%y2BrFx0fj@khar-pern.talamasca.ocis.net>

> When you say "mark forwards with a forgery-proof token the recipient can
> whitelist", do you really mean some kind of mark that gets applied to
> every message during forwarding? I don't think that would fly. If it

It would be an extra argument to MAIL FROM: during the transaction
between the forwarder and one of the recipient's border MXs.

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

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Michael Deutschmann wrote:
> On Sun, 28 Jan 2007, you wrote:
> > (That's because I seem to have missed it. Can you point me to the
> > message where you originally made that suggestion?)
>
> It's:
>
> Date: Mon, 15 Jan 2007 16:45:16 -0800 (PST)
> From: Michael Deutschmann <michael@talamasca.ocis.net>
> Subject: Re: [spf-discuss] Re: The forwarder's perspective
> Message-ID: <%y2BrFx0fj@khar-pern.talamasca.ocis.net>

Oh, that. I still have that message of yours in my inbox marked as
"unread" because I haven't found the time yet to think it through
completely. Will do soon.

> > When you say "mark forwards with a forgery-proof token the recipient
> > can whitelist", do you really mean some kind of mark that gets applied
> > to every message during forwarding? I don't think that would fly. If
> > it
>
> It would be an extra argument to MAIL FROM: during the transaction
> between the forwarder and one of the recipient's border MXs.

Well, I got _that_ idea of yours. It, too, has a problem, albeit a
different one. Who stops spammers (or other abusers) from offering the
same token in their MAIL FROM command? You'd again need some kind of
authentication mechanism (similar to SPF, but separate) to determine
whether the use of the white-listing token is legitimate. Or, if the
token was a cryptographic signature, it wouldn't be any different from SES
(or DKIM, if it covers the message header and/or body).

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

iD8DBQFFvUsOwL7PKlBZWjsRAkiSAJwOwnfjRm+JItczVSYeTq6WheZrjwCgwlHy
XFwc/7l8oysmcdc0ub/W8mo=
=fnJy
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Michael Deutschmann wrote on Sunday, January 28, 2007 3:34 PM -0600:

> That reminds me -- you never responded to my suggestion that the
> TENBOX requirements should be split into two. There should be a
> TENBOX Authentication protocol that forwarders to mark their
> forwards with a forgery-proof token the recipient can whitelist,
> and a TENBOX Authorization protocol that allows a forwarder to
> request whitelisting from the recipient MTA with no more enduser
> involvement than subscribing to a mailing list.

An interesting way to facilitate whitelisting. Unless you're proposing
a new ESMTP extension or putting this information into the headers, this
means changing the return-path and that will likely end up similar to
SRS. In that case, there's no need for whitelisting. There's nothing
stopping any forwarder today from implementing their own private flavor
of SRS to accomplish that. As long as you use the forwarding domain
name in the return-path and somehow give yourself the ability to route
DSN's to the original recipient, you've accomplished the goal.

Forwarder whitelisting is another matter, as it suggests the forwarding
domain is immune to spam complaints, and that's a much higher level of
trust. I don't see a great deal of motivation for large recipient
systems, who will often be the target of forwards, to whitelist such
mail and then deal with spam complaints for messages they wouldn't have
accepted themselves. Forwarders can correctly say their users
_required_ them to forward all received messages, except the users
didn't like the result and then complained to the target domain. End
users don't understand that the majority of spam is blocked due to the
identity of the source, not the content, so the target system looks like
the right place to complain.

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Mon, 29 Jan 2007, Seth Goodman wrote:

> accepted themselves. Forwarders can correctly say their users
> _required_ them to forward all received messages, except the users
> didn't like the result and then complained to the target domain. End
> users don't understand that the majority of spam is blocked due to the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> identity of the source, not the content, so the target system looks like
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the right place to complain.

Ah! You nailed it. *That* is what is driving the insanity. (Users
forward their mail to AOL and then mark it as spam, and then wonder
why their forward, and everyone elses at their company stops working.)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735