> well, technically, they (UCEProtect) are correct.
Sure, if I shoehorn my own rules, I can almost guarantee that _I_ will be compliant. That doesn't make them any more relevant though. > If an IP sends a mail with the From: header indicating a domain for > which an SPF record exists, and the sending IP is not supposed to send > it, then it is a misconfiguration and that IP should not be trying to > send such a mail at all. But SPF is supposed to be applied to the SMTP envelope address, NOT whatever happens to be put into any header lines... For headers you got your other voodoo, like DKIM. And I'm also not so sure that this is a misconfiguration, since that would assume I'd give SPF the same kind of authority as I give basic SMTP relaying, which I don't. I'll repeat myself: SPF is broken by design. But, I'll actually consider putting in an option into our mail configuration pannels, that lets customers who are forwarding mail to 3rd party servers, reject inbound mails if their forwarding would violate the sender policy. After all, it's our customers who pay us to handle their mail, not external mail senders, and thus customers should have the last word in this decision. Given though how many mail delivery errors never make it back to the sender, I wonder if this added complexity would really be beneficial. My gut feeling is: nope. The reply of UCEProtect fits my impression I got of them, and it confirms to me that I can't take them seriously. I'll let them throw tantrums in their playpen and move on. Cheers, Markus _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
