TMDA Re: [Gllug] New worm doing the rounds?

[will]

Jason Clifford wrote:
> On Wed, 18 Feb 2004, will wrote:
> 
> 
>>> It's more than convenience. The alternative is being forced into
>>> single supplier lock in. That will lead to effective monopolies
>>> if carried.
>> 
>> Um, which single supplier are you getting your SPF from?  Or are
>> you talking about having to use a single supplier for your SMTP
>> services. Well, if you use anything at ukfsn.org or
>> anything at something.ukfsn.org you are still using a single supplier,
>> whoever you use for your SMTP.
> 
> I'm not talking about just the SMTP element. SPF has the potential to
>  force users to use the same supplier for SMTP and their 'net
> connection and as email addresses tend to be harder to change
> wholesale it will lock in a lot of users to a single supplier for
> both elements.
> 
> No ukfsn user is forced to use our access services in order to send
> an email indicating the correct from address.
> 
> We already implement SMTP AUTH and a lot of our more savvy users
> already make use of the facility however UKFSN is not a typical ISP.
> The users are not, generally speaking, the same kind of users one
> might expect at AOL or other large ISPs.
> 
> In addition to running UKFSN I also run UKPOST.COM and offer similar
>  services there. I get far more problems with UKPOST users when they
> want to use SMTP AUTH than UKFSN ones.
> 
> I don't see SPF being implemented liberally by very many sites.

Well, maybe large ISP's will collectively publish wildcard, or no SPF 
records forcing mail admins to be liberal with the way they interpret 
the data.  Alternatively ISP's may be forced to change the way they 
work, ie by attempting to get users to use SMTP auth, or they will only 
allow sending from a user dialed up to their account with that ISP.

Either way, ISP's will be in the same boat and small ISP's are going to 
be just as able to compete by deploying the same SPF compliant 
technologies as much as larger ISPs.  For instance, if BT makes all 
users use smtp auth, and so do you, you are no worse off.  If BT forces 
users to dial up to send email but without auth, you can allow unauthed 
sending from your dialup too, but you can also offer authed SMTP from 
outside, and then you are more competitive.  Think of it as an 
opportunity ;)

> You've already indicated that you are considering using it to reject
> mail rather than as a scoring mechanism in a larger overall policy
> prior to rejecting messages.

Well, yes.  but only if the sender fails the test.  This will mean that
if the administrator for the sender domain had an SPF policy stating
'hosts x and y and IP range z/24 are allowed to send email for this
domain' and someone sent an email to me from host 'a' allegedly from a
user at that domain then the SPF policy would have been violated and the
mail would not get accepted.

As the administrator of a number of domains and a corporate email
system, I would prefer email to be rejected if it looks like it is from
one of my domains but not from an authorised host and will publish SPF
records in support of this.  An ISP such as yourself may publish more
lenient SPF records, and I believe AOL's SPF records state the servers
that are allowed to send aol.com email, and then state that if a host 
does not match one allowed to send from this domain 'accept the email as 
if no SPF record existed'.

If you don't put up SPF records, or use wildcards for ukpost or ukfsn,
the email from those domains will pass through my SPF check anyway and 
then be spam checked along with email that passes SPF checks dues to 
adhering to an SPF policy.

> Like you many others are seeking a solution now and the sad truth is
> that very many sites/domains are administered by people who lack your
>  understanding and skills.

<blush> :-).  Yeah, they are going to lose mail if they do it wrong. 
When I implemented RBL and FQDN HELO checking on a server I run for 
about 50 domains (some commercial) I was making a tradeoff between 
blocking spam (30000 emails blocked in the last 30 days BTW) and the 
very occaisional false positive from a mis-configured mailer.  After a 
while I had to remove the FQDN HELO check as too many users complaining 
of people not being able to send them mail (from what they did not know 
were mis-configured MTAs).   The FQDN HELO check tradeoff was not worth 
it for my users for the amount of spam it blocked so it went.  If my 
users complain about not getting SPF violating email, maybe I will 
implement spamassasin and just make SPF violation a 2 point offense, and 
I can re-introduce non FQDN HELO as a 1.5 pointer or something ;)

Oh I do love the power :)

> While I acknowledge many possible benefits from schemes like SPF the
>  downsides are far too great from my perspective.

 From my perspective it is a cool thing ;)  I admit that from yours it 
might mean extra work, but I don't think it will be the end of the world.

> It's wroth remembering that for many of us the primary concern is 
> fulfilling our roles are service providers and in my case that means
>  making sure mail is delivered properly. Any scheme that prevents or
>  substantially interfers with that is unlikely to gain my support.

The amount of man hours wasted at the moment at my company deleting spam 
makes SPF, even as just another tool in our anti-spam toolbox, look 
quite attractive.  I even *want* those restrictions on my personal domains.

> For service providers there may also be legal implications to such
> schemes as implementing them amounts to interference in private
> communications.

As I assume there are also issues with using RBLs.  ISP's may need to 
update Terms and conditions or something...

Will.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug