Mailing List Archive

spf wrote:

> How should a hosting service implement spf records when
> customers use ISPs that block port 25 and client software
> that does not support SASL ?

If I understand this correctly the hosting service sells
domains with Web-space, and offers an MX and an SMTP relay
for these domains. But some users can't use the relay,
because their ISP blocks port 25, and their software does
not support SMTP AUTH port 587.

Therefore these customers prefer to use the SMTP relay of
their ISP. In that case they have an address at this ISP,
and they could use MAIL FROM:<address@ISP> together with
a From:<catchall@domain.hoster>.

Another solution could be to offer SMTP-after-POP at port
587, and force a MAIL FROM domain matching the identified
user at his current IP. This variant of SMTP-after-POP
doesn't allow a forged MAIL FROM.

If the users insist on MAIL FROM:<catchall@domain.hoster>
sent via the SMTP relay of their ISP, and if the ISP allows
this (bad idea), then these users have to define their own
SPF records depending on their ISPs. Maybe something like
"v=spf1 include:defaults.hoster a:copied.from.mua ?all".

Bye, Frank


-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com

Frank Ellermann wrote:

>spf wrote:
>
>
>>How should a hosting service implement spf records when
>>customers use ISPs that block port 25 and client software
>>that does not support SASL ?
>>
>>
>
>If I understand this correctly the hosting service sells
>domains with Web-space, and offers an MX and an SMTP relay
>for these domains. But some users can't use the relay,
>because their ISP blocks port 25, and their software does
>not support SMTP AUTH port 587.
>
>Therefore these customers prefer to use the SMTP relay of
>their ISP. In that case they have an address at this ISP,
>and they could use MAIL FROM:<address@ISP> together with
>a From:<catchall@domain.hoster>.
>
>Another solution could be to offer SMTP-after-POP at port
>587, and force a MAIL FROM domain matching the identified
>user at his current IP. This variant of SMTP-after-POP
>doesn't allow a forged MAIL FROM.
>
>If the users insist on MAIL FROM:<catchall@domain.hoster>
>sent via the SMTP relay of their ISP, and if the ISP allows
>this (bad idea), then these users have to define their own
>SPF records depending on their ISPs. Maybe something like
>"v=spf1 include:defaults.hoster a:copied.from.mua ?all".
>
>

It sounds to me like the customer needs to upgrade the
client software. If they want to go to the trouble of
setting up SPF, downloading a new email program should
be trivial by comparison.

Bending over backwards to accommodate outdated software
is only going to introduce opportunities to compromise
the security of the system. The whole idea of SPF is
to increase the difficulty of forging mail. The more
companies involved, the more cracks there are to slip
through.


Just my $0.02
-- Terrel

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com

Terrel Shumway wrote:

> It sounds to me like the customer needs to upgrade the
> client software. If they want to go to the trouble of
> setting up SPF, downloading a new email program should
> be trivial by comparison.

Depends, if their ISP has a sender policy, they can just
include it into their policy. If the ISP has no policy,
and the customers have no clue what their iSP really does
(e.g. mailouts behind the MSA), then yes, that could be
difficult.

But you never say "upgrade your software" to a customer,
you offer a link to a piece of software acting as smtpd
to the old MUA, and as 2476 client to the real MSA. Of
course it's harder than changing the MUA, but that's not
your problem... ;-)

> Bending over backwards to accommodate outdated software
> is only going to introduce opportunities to compromise
> the security of the system.

SMTP-after-POP is IMHO not necessarily bad, if MAIL FROM
and IP must match the last successful POP3 login. But if
really old software doesn't allow to use port 587, then
it's probably _too_ old.

The case where the proud owner of "my.site.example" wants
to use MAIL FROM:<webmaster@my.site.example>" at his ISP,
although this ISP has nothing to do with the hoster of
my.site.example, is probably typical.

When this user starts to get spam at fake@my.site.example
and bounces to forged@my.site.example, it should be easy
to explain SPF and MSA. But before he hasn't seen this
for his own domain, he won't be happy if he can't use his
domain anymore at his ISP != hoster. Tough dilemma... :-(

Bye, Frank


-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com

On Jul 8, 2004, at 12:13 PM, spf wrote:

> How should a hosting service implement spf records when customers
> use ISPs that block port 25

Configure your SMTP server to take "submissions" on port 597.

> and client software that does not
> support SASL ?

Note that the mail clients don't need to support SASL, but they do need
to support SMTP AUTH. Are there really clients in use today that do
not do that?

-j

--
Jeffrey Goldberg http://www.goldmark.org/jeff/

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-help@v2.listbox.com