spf.pobox.com/faq.html#forwarding
All dom ains already publish email (MX) records to tell the world what machines receive mail for the domain. SPF works by domains publishing "reverse MX" records to tell the world wh at machines send mail from the domain. When receiving a message from a d omain, the recipient can check those records to make sure mail is coming from where it should be coming from. With SPF, those "reverse MX" records are easy to publish: one line in DNS is all it takes.
You should publish spf records for each and every domain you wish to protect from being used by spammers/virusses. Note that you will have to publish for each and every A record, including any wildcar d or @ entries in your dns.
Can I whitelist hosts on my dmz without making their adresses p ublicly available? Often, you will want to allow certain servers to send mail through your s mtp server. For example, if you have machines on your dmz that must be a ble to send status messages or you have some machines on your LAN that n eed to send out mail from your domain. In this case you will generally n ot want to publish these services in your public spf record (eg. First of all, many spf implementations pr ovide you with an option to put these adresses in a whitelist. This is j ust a list of hosts, which only needs to be available to your smtp serve r A second option is to implement a 'local policy'. For details, consul t the documentation that came with your specific spf implementation or s earch the list archives for 'whitelist' and 'local policy'.
You can not use your local dns server to publish txt records for your int ernet domains. You will have to use the dns server that serves your doma in to the internet. Contact your dns provider and/or your hosting compan y, or look in the webpanel your dns/domain hoster provides.
You can ask Hotmail if the IP address comes from their network. That record tells you (your computer) how to find out if the sending machine is allowed to sen d mail from Hotmail. If Hotmail says they recognize the sending machine, it passes, and you ca n assume the sender is who they say they are.
That means the return-pa th that shows up in "MAIL FROM", and to a lesser extent the HELO argumen t that is supposed to be an FQDN. The vast majority of SPF implementations today use the return-path as the subject of authentication and do not get involved with the header "From :". However, the tech nical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys.
SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version , this problem will be solved also. They have to change with the times, and p erform the above rewriting automatically for you.
Until the SRS patches are ready, the following workarounds will preserve the important functionality. com" This would make sure the sender address on bounces is "nobody", so if tha t bounce bounces, it would be junked. com" should of course exist and be mapped to the bit bucket. The most advanced solution is to forward bounces unless they contain the X-Loop token or the forwarding address. This is better than the first fo rm, which deletes all bounces, whether or not they'd cause a loop. com } This can even be combined with the above "-f nobody" solution, although i f the forwarding bounced once, there usually isn't much point in trying to forward the resulting bounce again, so delivering locally (at the for warding site) would then be better... You can't make an omelet without breaking eggs, and unfortunately forward ing is the egg that breaks. We're doing our best to patch it back togeth er with SRS.
We've heard the complaints -- Spammers can always get throwaway domains, etc. At a high level, the answer is that we're moving from one paradigm to ano ther: from "assumed innocent until proven guilty" to "assumed guilty unl ess proven innocent".
cartoon guide is availabl e) We agree that throwaway domains will be the next step in the arms race. W e can counter with: 1 fast automated blacklisting using spamtraps and attack detectors 2 simple reputation systems based on factors such as + age of domain according to whois + email profile of domain, eg. "too many unknown recipients" + call-back tests to see if the sender domain is able to receive mail. The reputation system can advise a receiving MTA to defer or reject. Here's an example of automated blacklisting in action: 1 A spammer spams. That domain is on a widely published sender-domain blacklist. That domain is a throwaway, just-registered domain, and does not yet appear on blacklists. Immediately before the display phase, the MUA re-tests the message against the blacklists, and discards it. Initially, 1 Most legitimate mail will fall into this category. If the volume of spam decreases, legal and administrative approaches beco me more effective; If there are only 10 spammers in the world, law enforcement can focus on catching each one . If there are 10,000 spammers, law enforcement throws up its hands, cal ls it a societal problem, and says it doesn't have enough resources to t ackle it.
all" for your domain, and you'll be able to send mail from your laptop no matter where you are. If you are the customer of an ISP that publishes SPF records, your ISP sh ould provide you with an SMTP server that you can authenticate to, using either POP-before-SMTP or SASL AUTH. Or you can ask them to exclude you from SPF using the a user-specific "exists" mechanism.
The return address claims to be from Blue Blo b Let's compare that to the postmark. Yup, the postmark says the messag e comes from Blue Blob. In email, the envelope sender, also known as the return path, is the retu rn address. The SMTP client is the post office that applied the postmark . Maybe a bad guy made up the return address to fool you into opening the envelope. Maybe a spammer forged a Paypal return addres s to try to get your credit card number.
Why should SPF succeed when similar proposals have failed in th e past? The spam problem was never as bad in the past as it is now. People are willing to put up with a lot more change and pain. com, which is willing to fund the development of S PF-enabling patches to MTAs, and to host the default fallback lookup dom ain for the purposes of guerilla adoption. People who have shown interest in supporting SPF include Qualcomm (makers of Eudora), Tim O'Reilly (publisher of geek books), SpamAssassin, Activ eState (makers of PureMessage), MailArmory, Declude JunkMail, and others .
Mail::SPF::Query provides a best_guess method, which pretends the domain had declared "a/24 mx/24 ptr". This is remarkably good at detecting unfo rged messages from domains which have not yet implemented SPF.
If y ou send mail from an unlisted server it will be rejected. Please don't m ake up bogus addresses if that would cause random third parties to get m ysterious bounce messages.
The big ones are for discussion and announcement s The little ones are for getting help with setting up SPF, and for dev elopers who are implementing SPF related software like client libraries and SRS rewriters.
Each subdomain at Demon is a different customer, and each customer mi ght have their own policy. It wouldn't make sense for Demon's policy to apply to all its customers by default; if Demon wants to do that, it can set up SPF records for each subdomain. So the advice to SPF publishers is this: you should add an SPF record for each subdomain or hostname that has an A or MX record.
When a domain has no MX records, we assume that an A record will suffice . Mail::SPF::Query provides a "best_guess" m ethod, which pretends the domain has "a/24 mx/24 ptr" defined. Even in t he absence of SPF data, we can suggest that a transaction is legitimate, (though we can't suggest that it is not legitimate, only that we don't know). And finding legitimate transactions helps other antispam approach es reduce false positives.
My existing spam filters work well enough, why do I need spf? The spam filter that runs in my MUA o r MDA catc...
|
http://csua.com/feed/