in reply to Re:x3 SPF for Perl Monks domains (no no no)
in thread SPF for Perl Monks domains

It is not bogus.
Yes it is :)

No, it's not.

Uh huh, and you have received joe-jobs that are not spam?

Yes, but that is not the point. Most joe-jobbed messages are indeed spam. And SPF can fix that. SPF cannot solve the spam problem altogether, but it can (when used) make sure spammers can't get away by using YOUR e-mailaddress.

SPF sets out to solve the wrong problem.

There is no "right problem" or "wrong problem". There is one problem that consists of many smaller problems. The big problem is spam, the smaller problems are those of open relays, joe-jobs, spamming viruses, etcetera. The battle against spam is one on many fronts, and SPF is on only one of them. That doesn't mean that what SPF does is wrong or that it solves the wrong problem.

There are legitimate reasons for other hosts in other domains to send email on behalf of the sender domain.

When the owner of the domain agrees, they can add the other hosts to the list. I don't want other people to send mail on my behalf without permission.

A number of prominent web sites, not the least of which is Ebay, but also includes any number of birthday card, e-postcard, street map sites will let a visitor send messages using their personal address to you (whether this is a good idea is another question -- but these services exist).

Ebay should never send email on my behalf. Birthday card sites, e-card sites, street map sites, tell-a-friend systems, etcetera, should never send email on my behalf.

They can and should use their own envelope from. If they have to, they can put the email address they say it's from in the From: header. But for the envelope, they should use their own address.

they can still set up a joe-job in the message body, by setting a From: spamcollector_perlmonks@juerd.nl or Reply-To: header

Put the envelope from in the headers and that is no longer a problem. The envelope from is already in my logs, so I can verify it whenever I want. The problem now is that the envelope from is unreliable without SPF.

Headers should not be trusted. I can send mail To: spamcollector_perlmonks@juerd.nl and have it delivered to your mailbox. Likewise, I can make it look like you sent it. This has never been a problem with real letters, so why does it have to be a problem with email? As long as the *envelope* has the correct information, things are okay.

That said, I note that I do check the From: header with SPF, even though SPF was not made or meant for that. I use it in combination with SpamAssassin with a score of 1.0, which is by itself not by far enough to flag the message as spam.

If you don't accept mail from proxies, zombies and trojans, residential broadband, American university dormitories and other sundry spamhavens your spam load drops to close to zero.

Yes, and it would also block out at least 10% of the legitimate mail I receive. No, thanks.

What I think you're really trying to say is that because SPF doesn't solve the entire spamming problem, it should not exist and is not worth any trouble. Is that your opinion?

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Replies are listed 'Best First'.
Re:x5 SPF for Perl Monks domains (no no no)
by grinder (Bishop) on May 15, 2004 at 21:03 UTC
    It is not bogus.
    Yes it is :)
    No, it's not.

    It is.

    There are legitimate reasons for other hosts in other domains to send email on behalf of the sender domain.
    When the owner of the domain agrees, they can add the other hosts to the list. I don't want other people to send mail on my behalf without permission.

    It is permitted in the current standard. Certainly, the standard was written at a time when spam and viruses were not a problem, but until it is amended, it is the standard and people are allowed to do that.

    That is not to say that I don't run my own correlation checks on the sender domain of the envelope. For instance, apart from a small number of whitelisted local ISPs, the only host that are permitted to send me yahoo.com email must have a domain name that also resolves to a Yahoo! server.

    Ebay [et al] should use their own envelope from.

    Why? If the email is undeliverable then they would have to do something about it, but it's not their problem. It's the problem of the person who sent the message initially. The return path mechanism works admirably well for this purpose.

    The problem now is that the envelope from is unreliable

    So forget about it. Deal with it another way. Stop fretting about what you're being sent and start paying attention to who is sending it. Don't add a DNS wart that breaks the existing standard in an attempt to fix it.

    This has never been a problem with real letters, so why does it have to be a problem with email?

    Atoms versus electrons. E-mail is not like real letters. The mail analogy breaks down if you push it far enough.

    If you don't accept mail from proxies, zombies and trojans, residential broadband, American university dormitories and other sundry spamhavens your spam load drops to close to zero.
    Yes, and it would also block out at least 10% of the legitimate mail I receive. No, thanks.

    Really?

    I don't think you understand what I'm saying. You let hosts with dynamic IP addresses connect directly to your server? Any old ppp, dialup or dhcp connection? And this accounts for 10% of your email? No wonder you're looking to fix a problem, but I think you're focussing on the wrong aspect. Deal with the client, and then you won't have to worry about the sender.

    What I think you're really trying to say is that because SPF doesn't solve the entire spamming problem, it should not exist and is not worth any trouble. Is that your opinion?

    No, that's not what I am saying. I quite agree that any technique that proposes a method of diminishing the amount of spam, viruses or anti-virus warning messages I receive is worth considering. In the case of SPF, I looked at it and found it wanting. While the benefits appear interesting, the fact that it breaks the existing standard makes it next to worthless. If it can be reworked so as not to break forwarding, then I'll be all in favour of it, but until then indeed it should not exist.

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Perl Monks Discussion