Hi Daniel

We're using SPF DNS entries for our own domain and on demand the domains of our customers. We're checking SPF entries on our spamfilter and filtering ~and - entries

My 2cents: If SPF ist setup correctly, it makes sense for those who check it and doesn't hurt those who don't...

Regards,

Mike

-- Mike Kellenberger mike.kellenberger@escapenet.ch Escapenet - the Web Company Tel +41 52 235 0700 http://www.escapenet.ch http://www.escapenet.ch/ Skype mikek70atwork

________________________________

Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Daniel.Blaser@lkw.li Gesendet: Mittwoch, 14. Februar 2007 15:35 An: swinog@swinog.ch Betreff: [swinog] to SPF or not to SPF

Hi Maillist,

SPF is starting to become a topic at our company again - ^^ - and I'm now interested:

- who does not use SPF - who implemented SPF DNS entries - who uses SPF for matching - who fully uses SPF ^^ lolz

I'm just trying to get a general feeling again about what the community thinks about SPF.

Kind regards,

Daniel

we're not using spf at all. i think there's every year a new discussion about it. check out the archive ;-)

-steven

________________________________

From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Daniel.Blaser@lkw.li Sent: Wednesday, February 14, 2007 3:35 PM To: swinog@swinog.ch Subject: [swinog] to SPF or not to SPF

Hi Maillist,

SPF is starting to become a topic at our company again - ^^ - and I'm now interested:

- who does not use SPF - who implemented SPF DNS entries - who uses SPF for matching - who fully uses SPF ^^ lolz

I'm just trying to get a general feeling again about what the community thinks about SPF.

Kind regards,

Daniel

Bonjour,

Norbert Bollow wrote:

Use DomainKeys instead of SPF. DomainKeys serves the same purpose, but doesn't share the fundamental brokenness of SPF.

And why not using the existing authentication protocol on outgoing smtp server ? So the sender can use the smtp server of the provider of its email address from any network and SPF can work without any problem.

Did i forget anything ?

Best regards,

Roger Buchwalder wrote:

That would be a nice solution, but explain that to a user...

We did it, and that was fine as they are only 2 boxes to click on outlook/outlookexpress, and still easy enough on mozilla/thunderbird with more mature users :-)

All are very happy as they don't have to change their outgoing smtp when they move.

We were also afraid at the beginning, and it is now a commercial advantage.

Best regard,

Adrian Ulrich wrote:

...

And why not using the existing authentication protocol on outgoing smtp server ? So the sender can use the smtp server of the provider of its email address from any network and SPF can work without any problem.

How would this solve the forwarding problem?

Sorry, i don't understand the forwarding problem...

And how are you going to teach everybody to stop doing something that has been working fine for years?

We have sent an email and had some more calls during 1st week afer email. But you can take the rythm you want to make people change, as the 2 systems can work together.

Best regards,

Hi,

1. Serious design flaws (such as the forwarding problem).

SPF is there to prevent mail with your sender envelope address to be relayed/forwarded by mailservers that are not meant to use your address. When you forward a mail in your MUA, you don't use the original sender in the From: header, do you? When a mailserver is relaying mail it is supposed to use its own sender envelope address. One possibility for that is SRS.

2. Peopele who don't understand SPF. If the not-understandig is a

mailserver admin it gets fatal (and lots of them are).

Both leads to legitimate rejected mail (And not just "some" false positives, sometimes complete domains get locked out by mailservers).

So consider....

That is a problem which in not restricted to SPF. If a mailadmin doesn't know how to use an RBL and blocks everything, then he can't be helped.

• Think twice before publishing SPF Records for your Domains.

There are admins in the wild who treat "neutral" as "hard fail".

I haven't had the chance to be in this situation yet.

• I use SPF to reject mails with spoofed origings from my private

mailserver. The number of rejected mails because of failed SPF checks is less than one percent of all REJECTED email. If I wouldn't be doing it for studies about mail, SPAM and means against it I'd completely let it be. It's not worth the effort to support a standard which is broken by design and so rarely used.

If you consider SPF to be the solution against all kinds of SPAMs then you will indeed be disapointed. SPF is meant to prevent the abuse of your domain as mail envelope from address. There are still worms out there that use harvested e-mail addresses as sender. And when the people receiving this kind of spam come back to you, you can at least tell them: hey, we published spf records to show you which IPs are allowed to send mail with this envelope address. if you don't check it and accept the obvious forgery, then it's your problem.

Regards,

Jean-Pierre

Well, you'd think that would be true, but I travel frequently, and there are actually hotels that have outsourced their guest IP service to clueless operators that block outgoing traffic to port 25, and insist that one use their own SMTP server (about which they fail to tell you until you get one of their support people to answer the phone).

So I would suggest offering SMTP (AUTH) support on ports 25 and 26, just to be sure. fastmail.fm do this -- it's a real lifesaver. But fastmail alow and encourage their clients to send via their SMTP from any domain, which discourages the use of SPF in any meaningful way.

SMTP-After-Pop is pointless -- it is broken in Outlook up to 2003.

Charles

-----Original Message----- From: Bernard Dugas [mailto:bernard.dugas@is-production.com] Sent: Friday, February 16, 2007 8:47 AM To: swinog@swinog.ch Subject: Re: [swinog] to SPF or not to SPF

And in complement to that, if we give to our customers some outgoing smtp servers with authentification they can use from any hotel/wifi in the world, there is no more reason that any email with your domain-names are sent from other smtp servers than ours, published with SPF in DNS.

And the customer is happy because he doesn't have to change smtp server each time he travels :-)

Adrian,

Aren't you making an error in reflection (Überlegungsfehler)?

If the provider on which one is guesting has a policy to block outbound access from their network to all ports used for sending of mail, so that they can force one through their SMTP server for sake of control, micromanagement, or whatever, then (assuming they know about it), would they not then block official port 587 as well as port 25? That was the position I heard the 'customer service rep' take the last time I tried to solve such a problem through appeal to bureaucratic sensibility.

Of course non-standard allocation of a system port has its drawbacks, and one has to be aware that a new 'official' use might come along *and* be so wildly popular that the port might have to be freed for the official purpose. But that doesn't happen often. There are times when throwing rules at a problem doesn't add value.

If the problem one is to solve is to add value for one's customers in spite of a sandbagging bureaucracy who are never held responsible for their actions, there may be no other way. At least that is the thinking of fastmail, who have done what I recommended for years. I only recommended following their example as it has been going on for so long as to be come a 'standard' non-standard. Microsoft have proceeded similarly on many occasions, and have almost always gotten away with it.

Charles

-----Original Message----- From: Adrian Ulrich [mailto:swinog@blinkenlights.ch] Sent: Sunday, February 18, 2007 9:58 AM To: swinog@swinog.ch Subject: Re: [swinog] to SPF or not to SPF

So I would suggest offering SMTP (AUTH) support on ports 25 and 26, just

to

be sure.

No no no.

RFC: 2476:

| 3. Message Submission | 3.1. Submission Identification | | Port 587 is reserved for email message submission as specified in | this document. Messages received on this port are defined to be | submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with | additional restrictions as specified here. | | While most email clients and servers can be configured to use port | 587 instead of 25, there are cases where this is not possible or | convenient. A site MAY choose to use port 25 for message submission, | by designating some hosts to be MSAs and others to be MTAs.

Port 587 has been widely deployed:

$ telnet smtpauth.bluewin.ch 587 $ telnet mail.gmx.net 587 $ telnet smtp.gmail.com 587

Inventing new ports < 1024 is just plain wrong.

would they not then block official port 587 as well as port 25? That was the position I heard the 'customer service rep' take the last time I tried to solve such a problem through appeal to bureaucratic sensibility.

There isn't really a (valid) reason to block port 587:

Blocking outgoing connections to port 25 may be done in order to block some zombie-networks (but IMO this is just silly.. will they also block port 80 soon to stop this blog-spamming? .. anyway ..)

..but you cannot spam using port 587 (unless you've been hijacking a valid account):

An smtpd running on port 587 must not accept mails from unauthenticated clients for any recipients:

Connected to smtpauth.bluewin.ch. 220 tr12.bluewin.ch ESMTP Service (Bluewin 7.3.121) ready helo bla 250 tr12.bluewin.ch mail from:<> 530 authentication required for mail submission

..only MUA/MSAs are supposed to use port 587.

Regards, Adrian

(Did anyone ever see/know an ISP blocking 587 ?)

On Fri, Feb 16, 2007 at 08:31:15AM +0100, Jean-Pierre Schwickerath wrote:

Hi,

...

1. Serious design flaws (such as the forwarding problem).

SPF is there to prevent mail with your sender envelope address to be relayed/forwarded by mailservers that are not meant to use your address. When you forward a mail in your MUA, you don't use the original sender in the From: header, do you? When a mailserver is relaying mail it is supposed to use its own sender envelope address. One possibility for that is SRS.

All mailing list forward mail with the original sender in the enveloppe and if you forward your mail on one server to another one with e.g. a simple .forward rule it will also re-use the same envelope from address. Forwarding mail is very common and it is important to use the same envelope form address in the forwarding path. Everybody who denies this fact does not understand the email system and the way bounces work.

On Fri, Feb 16, 2007 at 09:52:12AM +0100, Jean-Pierre Schwickerath wrote:

...

All mailing list forward mail with the original sender in the enveloppe

Not true: Mails from the swinog-mailinglist reach my mailserver with swinog-bounces@lists.swinog.ch as sender envelope address

Jup, my bad that's true most use some sort of VERPs. Unless it is a simple distribution list.

...

and if you forward your mail on one server to another one with e.g. a simple .forward rule it will also re-use the same envelope from address. Forwarding mail is very common and it is important to use the same envelope form address in the forwarding path. Everybody who denies this fact does not understand the email system and the way bounces work.

If you chose to forward mail this way, then you'd better make sure that the destination mail server doesn't apply spf checks for mails coming from the relaying server. or that the forwarding server rewrites the sender address.

If you're a provider that allows its users to forward their mail to remote addresses, then I'd advise you to use sender rewriting and thus offer your customers a reliable mail relaying. That's a marketing argument.

Woohoo. Breaking something and then requiring others to fix it for you and labeling something that is less reliable as "reliable". Let's see, I think that's summing it up perfectly: http://www.idrewthis.org/d/20060619.html

But in the end, everyone can do whatever they want to do ;-)

No they can't because of self-appointed Anti-SPAM marshals breaking deliberatly official standards causing marjor pain to others.

Nowadays, every sicko can buy a .com domain for 9$ or even less. Spammers buy domains, put correct SPF records in their zonefiles and throw the domain away afterwards... (just like you did with hotmail accounts a few years back :-))

So IMHO DNS based spam fighting doesn't work. At least not the SPF way...

Cheers, Viktor

Bernard Dugas wrote:

Bonjour,

Norbert Bollow wrote:

...

Use DomainKeys instead of SPF. DomainKeys serves the same purpose, but doesn't share the fundamental brokenness of SPF.

And why not using the existing authentication protocol on outgoing smtp server ? So the sender can use the smtp server of the provider of its email address from any network and SPF can work without any problem.

Did i forget anything ?

Best regards,

--- Bernard Dugas bernard.dugas@is-production.com wrote:

Sure, but at least, I know that no spamming is coming from my users and my outgoing smtp : small satisfaction for a small network :-)

what we did for a cable access network, is http://policyd.sourceforge.net/ configured for rate control. If a sender from a local dynamic IP pool sends more than 1000 emails in 15 minutes, its IP is automatically blocked for 24 hours, and the admins get a notifications. The admins were spending hours per week clearing the mailqueue and fighting the spambots, now they are no longer bothered.

In addition, the same policy daemon does greylisting on incoming email, and filters lots of incoming spam.

That's a great tool, but its internal design is a bit weak. I would gladly re-implement it if somebody would pay my time :)