SPF breaks email forwarding
Michael Scheidell wrote: -Original Message- From: Graham Murray [mailto:[EMAIL PROTECTED]] Sent: Monday, July 24, 2006 7:44 AM To: users@spamassassin.apache.org Subject: Re: New DNS Black list, White List, Yellow List Ramprasad <[EMAIL PROTECTED]> writes: A lot of banks/legitimate bulk email senders change their relay server. Many reasons for that. The most common is that they use a third party to relay their mails and these would keep changing Especially for banks and other high risk phishing targets, it would be much better if they did not do this. If all banks etc sent mail from a server whose IP address whose rDNS is xxx.bank.com and where xxx.bank.com resolves to the IP address from which the mail is sent, then it would considerably easier to detecting phishing and greatly improve the security for their customers. Even if the banks used spf hardfail, it would at least stop phishing to ISP's ans servers that knew about SPF. (you could bump SPF_HARDFAIL score to 15, or use spf to block offending connection right in postfix!) Except = SPF breaks email forwarding. It requires that the world change how email is forwarded and that's not going to happen. Thus if a bank has a hard fail and someone with an account on my server gets email from an account that is forwarded then my server sees the email as coming from an illegitimate source.
Re: SPF breaks email forwarding
Marc Perkel wrote: Except = SPF breaks email forwarding. It requires that the world change how email is forwarded and that's not going to happen. Thus if a bank has a hard fail and someone with an account on my server gets email from an account that is forwarded then my server sees the email as coming from an illegitimate source. This was in response to the posted who suggested the fix was to make banks use a defined reverse dns (which would NOT break forwarding?) old news, see SRS. If you want to go on a spf jihad, I suggest you do some research. Also, and if you require all mail servers to only take mail from xxx.bank.com, what good is that? doesn't that break how everyone receives email? What about marketing campaigns (yes, we hate them) with spf records, the DNS admin can coordinate email marketing campaigns. you have to reach into every mail server in the world and so something like.. spf. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131
Re: SPF breaks email forwarding
Michael Scheidell <[EMAIL PROTECTED]> writes: > Also, and if you require all mail servers to only take mail from > xxx.bank.com, what good is that? doesn't that break how everyone > receives email? No. It just rings very loud alarm bells when an email claiming to be from the bank comes from a server other than *.bank.com. It does, of course, require the user to check but this can be done either automatically by something like Spamassassin or using the Mk1 human eyeball to examine the message headers. It would not be necessary for the user to examine the headers of every message, just those claiming to come from 'high risk' (to the recipient) senders.
Re: SPF breaks email forwarding
> Except = SPF breaks email forwarding. It requires that the world > change how email is forwarded and that's not going to happen. Thus if > a bank has a hard fail and someone with an account on my server gets > email from an account that is forwarded then my server sees the email > as coming from an illegitimate source. > I know this is a troll subject Yes SPF breaks email forwarding, so does PTR checking ( which never was a great idea IMHO ). Every technique has some drawbacks. SPF has some but is still better than the rest When you want add security to an inherently insecure medium you cant say I will not change my servers. You want to put a .forward and receive mails from banks, get you mail- admin to use SRS. What is unreasonable in that ? Thanks Ram
Re: SPF breaks email forwarding
Ramprasad wrote: I know this is a troll subject Yes SPF breaks email forwarding, so does PTR checking ( which never was a great idea IMHO ). Every technique has some drawbacks. SPF has some but is still better than the rest When you want add security to an inherently insecure medium you cant say I will not change my servers. You want to put a .forward and receive mails from banks, get you mail- admin to use SRS. What is unreasonable in that ? you hit the nail on the head: If you want things to change, you have to change things. You cannot fix SMTP without breaking something. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131
Re: SPF breaks email forwarding
But I have no control over the servers that forward to me. Thus SPF is useless. Michael Scheidell wrote: Ramprasad wrote: I know this is a troll subject Yes SPF breaks email forwarding, so does PTR checking ( which never was a great idea IMHO ). Every technique has some drawbacks. SPF has some but is still better than the rest When you want add security to an inherently insecure medium you cant say I will not change my servers. You want to put a .forward and receive mails from banks, get you mail- admin to use SRS. What is unreasonable in that ? you hit the nail on the head: If you want things to change, you have to change things. You cannot fix SMTP without breaking something.
Re: SPF breaks email forwarding
Marc Perkel wrote: But I have no control over the servers that forward to me. Thus SPF is useless. so, again, bottom line: SMTP is broken. has been, phishing, forgeries, email viruses prove it. YOU fix it without breaking something. It can't be done. All you can do is compromise., and ps, SPF doesn't break forwarding, its the other way around: forwarding breaks SPF. If you can't come up with a proposal (something SPAML list has argued about for 12 years) to fix it without breaking it than there really is no need to attempt to educate you any further. Turn off SMTP, firewall port 25, no more email problems. -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131
Re: SPF breaks email forwarding
Domainkeys does less harm to forwarded messages than spf - a forwarder just has to put a Sender: header there, rother than implement srs Wolfgang Hamann >> >> Michael Scheidell wrote: >> >> -Original Message- >> >> From: Graham Murray [mailto:[EMAIL PROTECTED] >> >> Sent: Monday, July 24, 2006 7:44 AM >> >> To: users@spamassassin.apache.org >> >> Subject: Re: New DNS Black list, White List, Yellow List >> >> >> >> >> >> Ramprasad <[EMAIL PROTECTED]> writes: >> >> >> >> >> >>> A lot of banks/legitimate bulk email senders change their relay >> >>> server. Many reasons for that. The most common is that they use a >> >>> third party to relay their mails and these would keep changing >> >>> >> >> Especially for banks and other high risk phishing targets, it >> >> would be much better if they did not do this. If all banks >> >> etc sent mail from a server whose IP address whose rDNS is >> >> xxx.bank.com and where xxx.bank.com resolves to the IP >> >> address from which the mail is sent, then it would >> >> considerably easier to detecting phishing and greatly improve >> >> the security for their customers. >> >> >> > >> > Even if the banks used spf hardfail, it would at least stop phishing to >> > ISP's ans servers that knew about SPF. >> > >> > (you could bump SPF_HARDFAIL score to 15, or use spf to block offending >> > connection right in postfix!) >> > >> >> Except = SPF breaks email forwarding. It requires that the world change >> how email is forwarded and that's not going to happen. Thus if a bank >> has a hard fail and someone with an account on my server gets email from >> an account that is forwarded then my server sees the email as coming >> from an illegitimate source. >> >>
Re: SPF breaks email forwarding
On Mon, 24 Jul 2006, Ramprasad wrote:
> > Except = SPF breaks email forwarding. It requires that the world
> > change how email is forwarded and that's not going to happen. Thus if
> > a bank has a hard fail and someone with an account on my server gets
> > email from an account that is forwarded then my server sees the email
> > as coming from an illegitimate source.
[snip..]
> Yes SPF breaks email forwarding, so does PTR checking ( which never was
> a great idea IMHO ). Every technique has some drawbacks. SPF has some
> but is still better than the rest
> When you want add security to an inherently insecure medium you cant say
> I will not change my servers.
> You want to put a .forward and receive mails from banks, get you mail-
> admin to use SRS. What is unreasonable in that ?
An even better way to deal with this scenario; tell your customer:
"When you forward mail thru a 3'rd party it introduces potential
security risks. Your bank is not willing to tolerate those risks and
demands (via SPF-hardfail) that their messages get delivered directly
to their customers. When you (the customer) change ISPs you need to
go to your bank-account's profile and update the e-mail address.
To maintain security and reliability of delivery you should want to
do this."
That little dialog should impress the customer with your sincerity
and their bank's commitment to security (as well as redirect any
potential complaints to the bank, the bank made us do this ;).
It's also the simple truth. The analogy would be, if you move you
file a change-of-address with your bank, you don't trust the people
at your old apartment to always forward your bank statements to
your new home.
Dave
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: SPF breaks email forwarding
Hi, it seems to me that one of the big problems of email is the fact that email clients more or less hide the email address in favor of the display name, and that many users seem to lack the knowledge to check, let alone understand, message headers I guess most people should be able to notice the obvious discrepancy between sender address and display name that is present in many unwanted emails, if they were just seeing them Wolfgang Hamann >> Michael Scheidell <[EMAIL PROTECTED]> writes: >> >> > Also, and if you require all mail servers to only take mail from >> > xxx.bank.com, what good is that? doesn't that break how everyone >> > receives email? >> >> No. It just rings very loud alarm bells when an email claiming to be >> from the bank comes from a server other than *.bank.com. It does, of >> course, require the user to check but this can be done either >> automatically by something like Spamassassin or using the Mk1 human >> eyeball to examine the message headers. It would not be necessary for >> the user to examine the headers of every message, just those claiming >> to come from 'high risk' (to the recipient) senders. >>
Re: SPF breaks email forwarding
Whether it's SPF, DKIM, a combination of both or something completely new, the laissez-faire attitude of the past toward SMTP just doesn't cut it anymore. Criminals (and yes, I consider anyone who forges an identity to hide who they are a criminal no matter their intent) have taken advantage of the loose way in which SMTP was and still is implemented and they are causing considerable damage. If a few 'eggs' have to be broken on the way to securing our email systems than so-be- it. I agree with Michael Scheidell, "SMTP is broken. has been, phishing, forgeries, email viruses prove it." To make a statement like "SPF breaks email forwarding" and not offer an alternative merely makes you come off as a troll with an agenda. Now, I know from your contributions here that you are neither a troll or have an ulterior motive with such a statement but at the same time I can't even trust that the original email came from Marc Perkel <[EMAIL PROTECTED]>. As it stands, I can't trust the integrity of your domain 'perkel.com' since it does not have an SPF record. Anyone can claim to be you, even a troll. Now, you might say that s/mime could be the answer to that and you'd be correct but s/mime is expensive. Expensive in computer resources because it means that my server still has to receive every email, process it through virus and spam filters and then pass it on to me where what remains still has to be evaluated by me or my MUA. The idea behind SPF and its contemporaries is that obvious forgeries are handled by the MTA before entering the system for further evaluation, taking a huge load off the infrastructure we've been forced to put in place to deal with a system that is clearly, at present, broken. Personally, I think SPF, DKIM and any other workable proposal goes beyond just protecting me from spam, phishing and email viruses. It protects the integrity of my domains and further, the IP addresses in my control since I insist that all the domains I host on my server all have SPF records. People can trust that an email message claiming to come from one of my domains or from one of my IP addresses does in fact originate there. Thanks -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
I don't have an SPF record because I refuse to support a broken technology. SPF breaks email forwarding. My users use forwarding. SMTP is broken - but I can't change that. I have to be compatible with the rest of the world. Gino Cerullo wrote: Whether it's SPF, DKIM, a combination of both or something completely new, the laissez-faire attitude of the past toward SMTP just doesn't cut it anymore. Criminals (and yes, I consider anyone who forges an identity to hide who they are a criminal no matter their intent) have taken advantage of the loose way in which SMTP was and still is implemented and they are causing considerable damage. If a few 'eggs' have to be broken on the way to securing our email systems than so-be-it. I agree with Michael Scheidell, "SMTP is broken. has been, phishing, forgeries, email viruses prove it." To make a statement like "SPF breaks email forwarding" and not offer an alternative merely makes you come off as a troll with an agenda. Now, I know from your contributions here that you are neither a troll or have an ulterior motive with such a statement but at the same time I can't even trust that the original email came from Marc Perkel <[EMAIL PROTECTED]>. As it stands, I can't trust the integrity of your domain 'perkel.com' since it does not have an SPF record. Anyone can claim to be you, even a troll. Now, you might say that s/mime could be the answer to that and you'd be correct but s/mime is expensive. Expensive in computer resources because it means that my server still has to receive every email, process it through virus and spam filters and then pass it on to me where what remains still has to be evaluated by me or my MUA. The idea behind SPF and its contemporaries is that obvious forgeries are handled by the MTA before entering the system for further evaluation, taking a huge load off the infrastructure we've been forced to put in place to deal with a system that is clearly, at present, broken. Personally, I think SPF, DKIM and any other workable proposal goes beyond just protecting me from spam, phishing and email viruses. It protects the integrity of my domains and further, the IP addresses in my control since I insist that all the domains I host on my server all have SPF records. People can trust that an email message claiming to come from one of my domains or from one of my IP addresses does in fact originate there. Thanks -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Hello, is this really Marc? ;-) Sorry about the rant Marc, if that's you. I understand why you can't or won't implement SPF and I don't blame you under the circumstances. It's just that your statement was at best obvious and at the same time incomplete. A more accurate statement would have been, "SPF breaks email forwarding for my users and myself because my email forwarder does not support SRS" for which we would have said something like, "well don't use SPF" or better yet, "find a different email provider that has implemented SRS and you too can implement SPF." Other statements that would have been considered more acceptable to starting a conversation in general would have been, "SPF breaks email forwarding in present SMTP implemenations" or "SPF breaks email forwarding due to that lack of the wide spread implementation of SRS" but then we would have just said "Duh!" On 25-Jul-06, at 12:51 PM, Marc Perkel wrote: I don't have an SPF record because I refuse to support a broken technology. SPF breaks email forwarding. My users use forwarding. SMTP is broken - but I can't change that. I have to be compatible with the rest of the world. Again, it's not that SPF is a broken technology, it's that SMTP, at best, hasn't caught up to it yet or at worst, as has been stated already, is broken. Also, no one is forcing you to implement SPF, or are they? Tell me who they are, I'll send my boys. Gino Cerullo wrote: Whether it's SPF, DKIM, a combination of both or something completely new, the laissez-faire attitude of the past toward SMTP just doesn't cut it anymore. Criminals (and yes, I consider anyone who forges an identity to hide who they are a criminal no matter their intent) have taken advantage of the loose way in which SMTP was and still is implemented and they are causing considerable damage. If a few 'eggs' have to be broken on the way to securing our email systems than so-be-it. I agree with Michael Scheidell, "SMTP is broken. has been, phishing, forgeries, email viruses prove it." To make a statement like "SPF breaks email forwarding" and not offer an alternative merely makes you come off as a troll with an agenda. Now, I know from your contributions here that you are neither a troll or have an ulterior motive with such a statement but at the same time I can't even trust that the original email came from Marc Perkel <[EMAIL PROTECTED]>. As it stands, I can't trust the integrity of your domain 'perkel.com' since it does not have an SPF record. Anyone can claim to be you, even a troll. Now, you might say that s/mime could be the answer to that and you'd be correct but s/mime is expensive. Expensive in computer resources because it means that my server still has to receive every email, process it through virus and spam filters and then pass it on to me where what remains still has to be evaluated by me or my MUA. The idea behind SPF and its contemporaries is that obvious forgeries are handled by the MTA before entering the system for further evaluation, taking a huge load off the infrastructure we've been forced to put in place to deal with a system that is clearly, at present, broken. Personally, I think SPF, DKIM and any other workable proposal goes beyond just protecting me from spam, phishing and email viruses. It protects the integrity of my domains and further, the IP addresses in my control since I insist that all the domains I host on my server all have SPF records. People can trust that an email message claiming to come from one of my domains or from one of my IP addresses does in fact originate there. The only legitimate excuse I hear for not implementing SPF has to do with forwarding. There are situations beyond the control of the people involved that prevent them from implementing it. Until the default behaviour of an MTA is to implement SRS or SRS can easily be implemented in existing MTAs this will continue to be a problem. We'll just have to live with that for now. All the other excuses I hear regarding the lack of implementation of SPF are due to a lack of understanding of the protocol, laziness or the unfounded loss of control, "I refusal to implement a protocol that controls which email servers I can send my mail from," excuse. To them I say, SPF and its contemporaries are the future, you can either implement them or find your email in the bit bucket. The choice is yours. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Gino Cerullo wrote: involved that prevent them from implementing it. Until the default behaviour of an MTA is to implement SRS or SRS can easily be implemented I'd settle for just well defined, and actually usable. in existing MTAs this will continue to be a problem. We'll just have to live with that for now. Or we could just wait until it actually works right. You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. Daryl
RE: SPF breaks email forwarding
I only recently got spamassassin up and running and am hardly an expert but can anyone explain to me exactly what spf is? Tom -Original Message- From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 2:13 PM To: Spamassassin Users List Subject: Re: SPF breaks email forwarding Gino Cerullo wrote: > involved that prevent them from implementing it. Until the default > behaviour of an MTA is to implement SRS or SRS can easily be implemented I'd settle for just well defined, and actually usable. > in existing MTAs this will continue to be a problem. We'll just have to > live with that for now. Or we could just wait until it actually works right. You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. Daryl
Re: SPF breaks email forwarding
- Original Message - From: "Thomas Lindell" <[EMAIL PROTECTED]> I only recently got spamassassin up and running and am hardly an expert but can anyone explain to me exactly what spf is? See http://www.openspf.org/ for detailed information on SPF. Bill
RE: SPF breaks email forwarding
Oh, get off your high horse for a minute and stop trolling. This is a straw man argument, and I'm having none of it. SPF and forwarding don't go together, fine, I accept that. That does not make it useless, however - far from it. Don't reject at the MTA level based on things like SPF. Instead, use spamassassin appropriately and use the SPF info to add or subtract a little from the spamassassin score. In my experience of over 1,000,000 emails going through our spamassassin box since I turned on SPF support, it has broken nothing. A few emails have gotten seemingly erroneous SPF scores in spamassassin, but that has in no case been enough to misclassify any of them. But, I have to add, our Bayes database is very well trained. SPF has, on the other hand, helped push many spams over our spamassassin "spam" threshold. Cheers, Phil -Original Message- From: Marc Perkel [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 5:51 PM To: Gino Cerullo Cc: Spamassassin Users List Subject: Re: SPF breaks email forwarding I don't have an SPF record because I refuse to support a broken technology. SPF breaks email forwarding. My users use forwarding. SMTP is broken - but I can't change that. I have to be compatible with the rest of the world. Gino Cerullo wrote: > Whether it's SPF, DKIM, a combination of both or something completely > new, the laissez-faire attitude of the past toward SMTP just doesn't > cut it anymore. Criminals (and yes, I consider anyone who forges an > identity to hide who they are a criminal no matter their intent) have > taken advantage of the loose way in which SMTP was and still is > implemented and they are causing considerable damage. If a few 'eggs' > have to be broken on the way to securing our email systems than so-be-it. > > I agree with Michael Scheidell, "SMTP is broken. has been, phishing, > forgeries, email viruses prove it." > > To make a statement like "SPF breaks email forwarding" and not offer > an alternative merely makes you come off as a troll with an agenda. > Now, I know from your contributions here that you are neither a troll > or have an ulterior motive with such a statement but at the same time > I can't even trust that the original email came from Marc Perkel > <[EMAIL PROTECTED]>. > > As it stands, I can't trust the integrity of your domain 'perkel.com' > since it does not have an SPF record. Anyone can claim to be you, even > a troll. Now, you might say that s/mime could be the answer to that > and you'd be correct but s/mime is expensive. Expensive in computer > resources because it means that my server still has to receive every > email, process it through virus and spam filters and then pass it on > to me where what remains still has to be evaluated by me or my MUA. > > The idea behind SPF and its contemporaries is that obvious forgeries > are handled by the MTA before entering the system for further > evaluation, taking a huge load off the infrastructure we've been > forced to put in place to deal with a system that is clearly, at > present, broken. > > Personally, I think SPF, DKIM and any other workable proposal goes > beyond just protecting me from spam, phishing and email viruses. It > protects the integrity of my domains and further, the IP addresses in > my control since I insist that all the domains I host on my server all > have SPF records. People can trust that an email message claiming to > come from one of my domains or from one of my IP addresses does in > fact originate there. > > Thanks > -- > Gino Cerullo > > Pixel Point Studios > 21 Chesham Drive > Toronto, ON M3M 1W6 > > T: 416-247-7740 > F: 416-247-7503 > > >
RE: SPF breaks email forwarding
> -Original Message- > From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 25, 2006 3:13 PM > To: Spamassassin Users List > Subject: Re: SPF breaks email forwarding > > > > You find me a large scale installation that is actually checking, and > rejecting on, SPF records before DATA and isn't frequently rejecting > mail their users want and I'll buy you lunch. You find me a large scale installation that is rejecting SPAM and isn't frequently rejecting mail their users want and I'll buy dinner. Lets face it: SMTP is broken, but the fixes are just compromises between allowing spam, viruses, phishing and email. Any changes to SMTP will break legitimate email. You wonder what happens if you enforce all the RFC's on email? How many large installations use 'localhost.localdomain' as the FQDN for their outbound helo? (send an email to [EMAIL PROTECTED] and see the headers!) How many large installations doesn't use ANY fqdn for RDNS, and the PTR and A records don't match? How many large installations don't have abuse@ or postmaster@ records? http://www.rfc-ignorant.org/tools/lookup.php?domain=hotmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=gmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=yahoo.com (with a bad whois record, can't they lose their yahoo.com domain :-)? Even if you enforce existing RFC's, you will drop email 'users want'. For 12 years, people have been arguing about how to fix it. If someone wants to advertise spf records, and wants to use ?all, or ~all if they are timid, more power to them. host -t txt microsoft.com microsoft.com descriptive text "v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com ~all" host -t txt hotmail.com hotmail.com descriptive text "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" host -t txt _spf.google.com _spf.google.com descriptive text "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all" If a bank decides that forwarding email send to clients is a bad idea, and wants to publish -all records, that's fine also. If an ISP wants to trigger additional tests for email that softfails, or block at smtp session email that hardfails, then all they are doing is taking the suggestions of the sending domain. host -t txt chase.com chase.com descriptive text "v=spf1 ip4:170.148.48.0/24 ip4:159.53.36.0/24 ip4:159.53.46.0/24 ip4:159.53.110.0/24 -all"
Re: SPF breaks email forwarding
On 25-Jul-06, at 5:05 PM, Daryl C. W. O'Shea wrote:I'd settle for just well defined, and actually usable.Or we could just wait until it actually works right.That sounds reasonable. If the protocol is as sound as it appears to be, the MTA developers will make an effort to implement it. If not, then it just wasn't meant to be.You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. Daryl Hey, I never claimed checking and rejecting before DATA to be ready for 'large scale' deployments. ;-) But, I have to say that in the six months that I've been doing it I've never had a false positive. Also, I've been publishing an SPF record for over two years and again, I've never had a problem with mail being rejected, misdirected or lost.The truth is that there is no reason for any domain not to be able to publish SPF records that end in at least a SOFTFAIL (~all). It would at least allow filters like Spamassassin to have additional data to use in its scoring and a SOFTFAIL will not prevent forwarded email from reaching it's destination. Nobody in there right mind rejects on a SOFTFAIL. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: SPF breaks email forwarding
Gino Cerullo wrote: > Nobody in there right mind rejects on a > SOFTFAIL. After some of the "clever" implementations I've seen NOTHING would surprise me The word "muppetry" springs to mind :) -- Mr Michele Neylon Blacknight Solutions Quality Business Hosting & Colocation http://www.blacknight.ie/ Tel. 1850 927 280 Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 59 9164239
Re: SPF breaks email forwarding
On 25-Jul-06, at 5:05 PM, Bill Landry wrote: I only recently got spamassassin up and running and am hardly an expert but can anyone explain to me exactly what spf is? See http://www.openspf.org/ for detailed information on SPF. Bill There is also http://new.openspf.org/ If you are really interested you can subscribe to their mailing lists here http://new.openspf.org/Forums If you like you can email me directly as well. I would imagine that people are getting tired of us going off-topic on this list by now. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Michael Scheidell wrote: -Original Message- From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED] You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. You find me a large scale installation that is rejecting SPAM and isn't frequently rejecting mail their users want and I'll buy dinner. Luckily I'm on my way home for dinner now. In my mind there's a huge difference between rejecting mail based on the behaviour and actions of the sender than there is rejecting mail based on actions of the recipient (choosing to forward their mail). The only way I can see that they'd be the same is if you fault the sender for publishing SPF records. Lets face it: SMTP is broken, but the fixes are just compromises between allowing spam, viruses, phishing and email. Any changes to SMTP will break legitimate email. You wonder what happens if you enforce all the RFC's on email? How many large installations use 'localhost.localdomain' as the FQDN for their outbound helo? (send an email to [EMAIL PROTECTED] and see the headers!) How many large installations doesn't use ANY fqdn for RDNS, and the PTR and A records don't match? How many large installations don't have abuse@ or postmaster@ records? http://www.rfc-ignorant.org/tools/lookup.php?domain=hotmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=gmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=yahoo.com (with a bad whois record, can't they lose their yahoo.com domain :-)? Even if you enforce existing RFC's, you will drop email 'users want'. All actions of the sender, not the recipient. For 12 years, people have been arguing about how to fix it. If someone wants to advertise spf records, and wants to use ?all, or ~all if they are timid, more power to them. The record itself is not the issue. It's what action the recipient system takes based on the record. host -t txt microsoft.com microsoft.com descriptive text "v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com ~all" host -t txt hotmail.com hotmail.com descriptive text "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" OK, citing Microsoft's records wouldn't be my first choice when arguing in favour of SPF. For starters, they're basically saying we're not sure where our mail comes from... last time I counted their records covered over 11 million hosts. So everyone arguing about "security of email" can't seriously consider this a good example. Second, while they publish SPF compatible records, they treat other people's records more like PRA and even when they treat them as SPF they'll tell you that they don't even fully support SPF mechanisms. host -t txt _spf.google.com _spf.google.com descriptive text "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all" I have no idea what your point is here. If a bank decides that forwarding email send to clients is a bad idea, and wants to publish -all records, that's fine also. Why should that be up to the bank and not their customer. If their control over security needs to be that far reaching they should coat their ATM cards in something that prevents me from writing the PIN number on it with a permanent marker. There's a far better chance of my account being compromised that way then due to me forwarding mail from one system I, or someone I trust, control to another. Besides, even if the bank should have a say over whether you should be able to forward mail, what happens when your forwarder implements SRS. Oh no, the bank no longer has a say, they've lost the control they apparently should have. I guess it's a good thing that SRS is essentially vapourware. If an ISP wants to trigger additional tests for email that softfails, or block at smtp session email that hardfails, then all they are doing is taking the suggestions of the sending domain. I still maintain that blocking based on the actions of the end-user recipient isn't the right thing to do when it comes to sender authentication schemes. host -t txt chase.com chase.com descriptive text "v=spf1 ip4:170.148.48.0/24 ip4:159.53.36.0/24 ip4:159.53.46.0/24 ip4:159.53.110.0/24 -all" Hey, I recognize chase.com. They're the bank that goes out of their way to make their email look like phishing mail. Anyway... I'm sure the SpamAssassin user's list is getting bored now. Daryl
Re: SPF breaks email forwarding
Many people, including me, think SRS is a bad idea. So I'm not getting on board with a system that is clearly a mistake. Gino Cerullo wrote: Hello, is this really Marc? ;-) Sorry about the rant Marc, if that's you. I understand why you can't or won't implement SPF and I don't blame you under the circumstances. It's just that your statement was at best obvious and at the same time incomplete. A more accurate statement would have been, "SPF breaks email forwarding for my users and myself because my email forwarder does not support SRS" for which we would have said something like, "well don't use SPF" or better yet, "find a different email provider that has implemented SRS and you too can implement SPF." Other statements that would have been considered more acceptable to starting a conversation in general would have been, "SPF breaks email forwarding in present SMTP implemenations" or "SPF breaks email forwarding due to that lack of the wide spread implementation of SRS" but then we would have just said "Duh!" On 25-Jul-06, at 12:51 PM, Marc Perkel wrote: I don't have an SPF record because I refuse to support a broken technology. SPF breaks email forwarding. My users use forwarding. SMTP is broken - but I can't change that. I have to be compatible with the rest of the world. Again, it's not that SPF is a broken technology, it's that SMTP, at best, hasn't caught up to it yet or at worst, as has been stated already, is broken. Also, no one is forcing you to implement SPF, or are they? Tell me who they are, I'll send my boys. Gino Cerullo wrote: Whether it's SPF, DKIM, a combination of both or something completely new, the laissez-faire attitude of the past toward SMTP just doesn't cut it anymore. Criminals (and yes, I consider anyone who forges an identity to hide who they are a criminal no matter their intent) have taken advantage of the loose way in which SMTP was and still is implemented and they are causing considerable damage. If a few 'eggs' have to be broken on the way to securing our email systems than so-be-it. I agree with Michael Scheidell, "SMTP is broken. has been, phishing, forgeries, email viruses prove it." To make a statement like "SPF breaks email forwarding" and not offer an alternative merely makes you come off as a troll with an agenda. Now, I know from your contributions here that you are neither a troll or have an ulterior motive with such a statement but at the same time I can't even trust that the original email came from Marc Perkel <[EMAIL PROTECTED]>. As it stands, I can't trust the integrity of your domain 'perkel.com' since it does not have an SPF record. Anyone can claim to be you, even a troll. Now, you might say that s/mime could be the answer to that and you'd be correct but s/mime is expensive. Expensive in computer resources because it means that my server still has to receive every email, process it through virus and spam filters and then pass it on to me where what remains still has to be evaluated by me or my MUA. The idea behind SPF and its contemporaries is that obvious forgeries are handled by the MTA before entering the system for further evaluation, taking a huge load off the infrastructure we've been forced to put in place to deal with a system that is clearly, at present, broken. Personally, I think SPF, DKIM and any other workable proposal goes beyond just protecting me from spam, phishing and email viruses. It protects the integrity of my domains and further, the IP addresses in my control since I insist that all the domains I host on my server all have SPF records. People can trust that an email message claiming to come from one of my domains or from one of my IP addresses does in fact originate there. The only legitimate excuse I hear for not implementing SPF has to do with forwarding. There are situations beyond the control of the people involved that prevent them from implementing it. Until the default behaviour of an MTA is to implement SRS or SRS can easily be implemented in existing MTAs this will continue to be a problem. We'll just have to live with that for now. All the other excuses I hear regarding the lack of implementation of SPF are due to a lack of understanding of the protocol, laziness or the unfounded loss of control, "I refusal to implement a protocol that controls which email servers I can send my mail from," excuse. To them I say, SPF and its contemporaries are the future, you can either implement them or find your email in the bit bucket. The choice is yours. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
If any of my customers fail to get any email that they are supposed to get then that's not acceptable. It does happen and when it does - I fix it. Several of my customers forward email from other account to accounts that pass through my servers. So if I used SPF then I would lose email to these customers. Michael Scheidell wrote: -Original Message- From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 25, 2006 3:13 PM To: Spamassassin Users List Subject: Re: SPF breaks email forwarding You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. You find me a large scale installation that is rejecting SPAM and isn't frequently rejecting mail their users want and I'll buy dinner. Lets face it: SMTP is broken, but the fixes are just compromises between allowing spam, viruses, phishing and email. Any changes to SMTP will break legitimate email. You wonder what happens if you enforce all the RFC's on email? How many large installations use 'localhost.localdomain' as the FQDN for their outbound helo? (send an email to [EMAIL PROTECTED] and see the headers!) How many large installations doesn't use ANY fqdn for RDNS, and the PTR and A records don't match? How many large installations don't have abuse@ or postmaster@ records? http://www.rfc-ignorant.org/tools/lookup.php?domain=hotmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=gmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=yahoo.com (with a bad whois record, can't they lose their yahoo.com domain :-)? Even if you enforce existing RFC's, you will drop email 'users want'. For 12 years, people have been arguing about how to fix it. If someone wants to advertise spf records, and wants to use ?all, or ~all if they are timid, more power to them. host -t txt microsoft.com microsoft.com descriptive text "v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com ~all" host -t txt hotmail.com hotmail.com descriptive text "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" host -t txt _spf.google.com _spf.google.com descriptive text "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all" If a bank decides that forwarding email send to clients is a bad idea, and wants to publish -all records, that's fine also. If an ISP wants to trigger additional tests for email that softfails, or block at smtp session email that hardfails, then all they are doing is taking the suggestions of the sending domain. host -t txt chase.com chase.com descriptive text "v=spf1 ip4:170.148.48.0/24 ip4:159.53.36.0/24 ip4:159.53.46.0/24 ip4:159.53.110.0/24 -all"
Re: SPF breaks email forwarding
On 25-Jul-06, at 6:34 PM, Marc Perkel wrote: Many people, including me, think SRS is a bad idea. So I'm not getting on board with a system that is clearly a mistake. That's fine. You, along with everyone else, are entitle to your opinion. Furthermore, you along with those people are free to choose to implement a technology if it suits you. No one is forcing this on you or anyone else. At the same time, I am merely excising my freedom to voice an alternate view or opinion. The people reading this list will make up there own minds. Some may have even benefited from this thread. I am curious though. Why do you "think SRS is a bad idea" and what makes it "clearly a mistake." You appear to feel strongly about this but without an explanation it's hard to fathom why. Please elaborate. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Marc Perkel wrote: > So if I used SPF then I would lose email > to these customers. No you wouldn't unless someone was doing some kind of demented hard fail -- Mr Michele Neylon Blacknight Solutions Quality Business Hosting & Colocation http://www.blacknight.ie/ Tel. 1850 927 280 Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 59 9164239
Re: SPF breaks email forwarding
On 25-Jul-06, at 6:34 PM, Michele Neylon wrote: After some of the "clever" implementations I've seen NOTHING would surprise me The word "muppetry" springs to mind :) Ahh, but that's why I qualified my statement by saying, "Nobody in there right mind..." I notice your SPF record ends in NEUTRAL (?all) do you have a tale to tell or are you just being overly cautious for now? -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
RE: SPF breaks email forwarding
Title: Message -Original Message-From: Marc Perkel [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 6:43 PMTo: Michael ScheidellCc: Daryl C. W. O'Shea; Spamassassin Users ListSubject: Re: SPF breaks email forwarding If any of my customers fail to get any email that they are supposed to get then that's not acceptable. It does happen and when it does - I fix it. Several of my customers forward email from other account to accounts that pass through my servers. So if I used SPF then I would lose email to these customers. so, don't the best thing about spf is you need two willing partners. Michael Scheidell wrote: -Original Message- From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 25, 2006 3:13 PM To: Spamassassin Users List Subject: Re: SPF breaks email forwarding You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. You find me a large scale installation that is rejecting SPAM and isn't frequently rejecting mail their users want and I'll buy dinner. Lets face it: SMTP is broken, but the fixes are just compromises between allowing spam, viruses, phishing and email. Any changes to SMTP will break legitimate email. You wonder what happens if you enforce all the RFC's on email? How many large installations use 'localhost.localdomain' as the FQDN for their outbound helo? (send an email to [EMAIL PROTECTED] and see the headers!) How many large installations doesn't use ANY fqdn for RDNS, and the PTR and A records don't match? How many large installations don't have abuse@ or postmaster@ records? http://www.rfc-ignorant.org/tools/lookup.php?domain=hotmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=gmail.com http://www.rfc-ignorant.org/tools/lookup.php?domain=yahoo.com (with a bad whois record, can't they lose their yahoo.com domain :-)? Even if you enforce existing RFC's, you will drop email 'users want'. For 12 years, people have been arguing about how to fix it. If someone wants to advertise spf records, and wants to use ?all, or ~all if they are timid, more power to them. host -t txt microsoft.com microsoft.com descriptive text "v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com ~all" host -t txt hotmail.com hotmail.com descriptive text "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" host -t txt _spf.google.com _spf.google.com descriptive text "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all" If a bank decides that forwarding email send to clients is a bad idea, and wants to publish -all records, that's fine also. If an ISP wants to trigger additional tests for email that softfails, or block at smtp session email that hardfails, then all they are doing is taking the suggestions of the sending domain. host -t txt chase.com chase.com descriptive text "v=spf1 ip4:170.148.48.0/24 ip4:159.53.36.0/24 ip4:159.53.46.0/24 ip4:159.53.110.0/24 -all"
Re: SPF breaks email forwarding
Gino Cerullo wrote: I am curious though. Why do you "think SRS is a bad idea" and what makes it "clearly a mistake." You appear to feel strongly about this but without an explanation it's hard to fathom why. Please elaborate. Because I do conditionals based on the from address and if the from address is mangled then I can't do my from conditionals.
Re: SPF breaks email forwarding
Michele Neylon :: Blacknight.ie wrote: Marc Perkel wrote: So if I used SPF then I would lose email to these customers. No you wouldn't unless someone was doing some kind of demented hard fail Yes - and other people do use hard fail.
Re: SPF breaks email forwarding
On Tue, 25 Jul 2006, Marc Perkel wrote: > If any of my customers fail to get any email that they are supposed to > get then that's not acceptable. I think that's a big problem right there. Since when did "guaranteed delivery" become part of email? -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Look at the people at the top of both efforts. Linus Torvalds is a university graduate with a CS degree. Bill Gates is a university dropout who bragged about dumpster-diving and using other peoples' garbage code as the basis for his code. Maybe that has something to do with the difference in quality/security between Linux and Windows. -- anytwofiveelevenis on Y! SCOX --
Re: SPF breaks email forwarding
"John D. Hardin" <[EMAIL PROTECTED]> writes: > I think that's a big problem right there. Since when did "guaranteed > delivery" become part of email? Never, but the relative newcomers to email probably do not realise that. Email delivery has always been "best endeavour".
Re: SPF breaks email forwarding
Gino Cerullo schrieb: [...] > Hey, I never claimed checking and rejecting before DATA to be ready for > 'large scale' deployments. ;-) But, I have to say that in the six months > that I've been doing it I've never had a false positive. wood> Also, I've been publishing an SPF record for over two years and > again, I've never had a problem with mail being rejected, misdirected or > lost. > > The truth is that there is no reason for any domain not to be able to > publish SPF records that end in at least a SOFTFAIL (~all). [...] Well, maybe there is. Doesn't SA score SOFTFAIL with more than 1 point? regards, rolf begin:vcard fn:Rolf Kraeuchi n:Kraeuchi;Rolf org:Uni Bern;Informatikdienste adr:;;Gesellschaftsstr. 6;Bern;BE;3012;CH email;internet:[EMAIL PROTECTED] title:Postmaster tel;work:0316313180 tel;fax:0316313865 note:ICQ # 314824894 x-mozilla-html:FALSE url:http://www.id.unibe.ch version:2.1 end:vcard
Re: SPF breaks email forwarding
Sorry folks I agree without SPF ( or DK ?) it would very difficult to prevent forging. I am going to ask my DNS providers to publish SPF records immediately. Thanks to everyone for knowledge sharing On Tue, 2006-07-25 at 18:33 -0700, Marc Perkel wrote: > > > Michele Neylon :: Blacknight.ie wrote: > > Marc Perkel wrote: > > > > > So if I used SPF then I would lose email > > > to these customers. > > > > > > > No you wouldn't unless someone was doing some kind of demented hard fail > > > > > > > > Yes - and other people do use hard fail. >
Re: SPF breaks email forwarding
On 26-Jul-06, at 4:00 AM, Rolf Kraeuchi wrote:Gino Cerullo schrieb:[...] Hey, I never claimed checking and rejecting before DATA to be ready for'large scale' deployments. ;-) But, I have to say that in the six monthsthat I've been doing it I've never had a false positive. wood> Also, I've been publishing an SPF record for over two years andagain, I've never had a problem with mail being rejected, misdirected orlost.The truth is that there is no reason for any domain not to be able topublish SPF records that end in at least a SOFTFAIL (~all). [...] Well, maybe there is. Doesn't SA score SOFTFAIL with more than 1 point?regards,rolfNo, the default scores are as follows.SOFT_FAIL 0.5FAIL 0.9 --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: SPF breaks email forwarding
Gino Cerullo schrieb: > > On 26-Jul-06, at 4:00 AM, Rolf Kraeuchi wrote: > >> Gino Cerullo schrieb: >> [...] >>> Hey, I never claimed checking and rejecting before DATA to be ready for >>> 'large scale' deployments. ;-) But, I have to say that in the six months >>> that I've been doing it I've never had a false positive. >> wood> Also, I've been publishing an SPF record for over two years and >>> again, I've never had a problem with mail being rejected, misdirected or >>> lost. >>> >>> The truth is that there is no reason for any domain not to be able to >>> publish SPF records that end in at least a SOFTFAIL (~all). [...] >> >> Well, maybe there is. Doesn't SA score SOFTFAIL with more than 1 point? >> >> regards, >> rolf > > No, the default scores are as follows. > > SOFT_FAIL0.5 > FAIL 0.9 What version is that? My default scores for SA 3.1.3 are quite different: --- scores according to 50_scores.cf --- score SPF_FAIL 0 1.333 0 1.142 score SPF_SOFTFAIL 0 1.470 0 1.384 Hmm, SOFTFAIL scores higher than FAIL?? regards, rolf
Re: SPF breaks email forwarding
On Tue, July 25, 2006 18:51, Marc Perkel wrote: > I don't have an SPF record because I refuse to support a broken > technology. sigh > SPF breaks email forwarding. My users use forwarding. fair, but why not stop using forwarding ? > SMTP is broken - but I can't change that. if smtp is brokken, maybe spammers need better bullet prof mail servers ? > I have to be compatible with the rest of the world. amen -- Benny
Re: SPF breaks email forwarding
Rolf Kraeuchi <[EMAIL PROTECTED]> writes: > Hmm, SOFTFAIL scores higher than FAIL?? Maybe because some (many?) people reject SPF fail at SMTP time, so spam with SPF fail is not presented to SpamAssassin.
Re: SPF breaks email forwarding
On 26-Jul-06, at 10:46 AM, Graham Murray wrote: Rolf Kraeuchi <[EMAIL PROTECTED]> writes: Hmm, SOFTFAIL scores higher than FAIL?? Maybe because some (many?) people reject SPF fail at SMTP time, so spam with SPF fail is not presented to SpamAssassin. Actually this makes sense in my situation. I normally reject at the MTA on FAIL and let everything else through where it gets examined by SA. I have users who use AUTH to connect to my server from outside to send mail. The MTA correctly ignores the fact that they are connected from a unauthorized, according to SPF, IP address but because SA scans the outgoing email regardless, it scores that message as a FAIL. If the score was too high for FAIL then these legitimate messages could be rejected even before they left the sending server. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Gino Cerullo wrote: On 26-Jul-06, at 4:00 AM, Rolf Kraeuchi wrote: Gino Cerullo schrieb: [...] Hey, I never claimed checking and rejecting before DATA to be ready for 'large scale' deployments. ;-) But, I have to say that in the six months that I've been doing it I've never had a false positive. wood> Also, I've been publishing an SPF record for over two years and again, I've never had a problem with mail being rejected, misdirected or lost. The truth is that there is no reason for any domain not to be able to publish SPF records that end in at least a SOFTFAIL (~all). [...] Well, maybe there is. Doesn't SA score SOFTFAIL with more than 1 point? regards, rolf No, the default scores are as follows. SOFT_FAIL 0.5 FAIL 0.9 I suspect the low scores represent a high amount of false positives which is why I say SPF is broken.
Re: SPF breaks email forwarding
Benny Pedersen wrote: On Tue, July 25, 2006 18:51, Marc Perkel wrote: SPF breaks email forwarding. My users use forwarding. fair, but why not stop using forwarding ? Because my customers want to use forwarding.
Re: SPF breaks email forwarding
On Monday 24 July 2006 15:24, Marc Perkel took the opportunity to write: > Except = SPF breaks email forwarding. It requires that the world change > how email is forwarded and that's not going to happen. Thus if a bank > has a hard fail and someone with an account on my server gets email from > an account that is forwarded then my server sees the email as coming > from an illegitimate source. Not entirely true. It requires you to make exceptions for mail forwarded from those of your users' accounts elsewhere where SRS is not yet employed (which is not trivial, I must admit, but not impossible either) before enforcing such hardfails. The users must know where they are forwarding mail from and to. If mail comes any other way it's illegitimate, or at least indistinguishable from illegitimate mail. The problem is, of course, that it's generally not possible to know all outgoing MTAs of a domain, unless that domain also uses SPF, and in that case they also ought to know about SRS. If the intermediate system adds a Resent-From: header it also helps. Spammers can't know all the ways people forward mail. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpa22aXIP2NF.pgp Description: PGP signature
RE: SPF breaks email forwarding
> -Original Message- > From: Graham Murray [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 26, 2006 10:46 AM > To: users@spamassassin.apache.org > Subject: Re: SPF breaks email forwarding > > > Rolf Kraeuchi <[EMAIL PROTECTED]> writes: > > > Hmm, SOFTFAIL scores higher than FAIL?? > > Maybe because some (many?) people reject SPF fail at SMTP > time, so spam with SPF fail is not presented to SpamAssassin. > And, SPF is not an indication of SPAM vs HAM, but only of forgery? Or a lot of spam comes from large free email hosting companies that use SPF? SA scores based an a huge amount of email and even if it is suppressing that hardfail is scored lower than softfail, I wonder what the score for 'none', ie noneistant spf records would be ;-) If you don't like SPF, don't use it. The SENDING MAIL SERVER has to support it AND THE RECEIVER MAIL SERVER has to support it. If you run your own mail servers, and don't want to use it then DON'T. 99.% of the servers out there could publish valid or invalid SPF records and guess what: If you don't check for it, its not going to affect you! That seems to be something the anti-spf jihad seems to forget. If I publish -all (hardfail) records and you decide to bounce on hardfail, fine. If your ISP publishes and uses SPF records and you don't like it, move.
Re: SPF breaks email forwarding
On Wednesday 26 July 2006 00:42, Marc Perkel took the opportunity to write: > If any of my customers fail to get any email that they are supposed to > get then that's not acceptable. It does happen and when it does - I fix > it. Several of my customers forward email from other account to accounts > that pass through my servers. So if I used SPF then I would lose email > to these customers. You lose mail when it disappears without trace (without bounce message). Under no circumstance should an SPF hardfail cause that to happen (but the sender may be a machine that doesn't know what to do with the bounce). Blocking legitimate mail is bad, but not as bad as throwing it away. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpzS9KzhZqvq.pgp Description: PGP signature
Re: SPF breaks email forwarding
On Wednesday 26 July 2006 17:25, Marc Perkel wrote: > Benny Pedersen wrote: > > On Tue, July 25, 2006 18:51, Marc Perkel wrote: > >> SPF breaks email forwarding. My users use forwarding. > > > > fair, but why not stop using forwarding ? > > Because my customers want to use forwarding. Perhaps it would be fairer to say that SPF is fine but the forwarding is broken. Forwarding should (IMO) be implemented in such a way as the FORWARDING mailbox should be used as the new return-path (Just like if you forwarded an email from your MUA rather than with the MDA). Then both SPF and forwarding would work fine. And furthermore be consistent. Hamish. pgpHpRZ3hZIMD.pgp Description: PGP signature
Re: SPF breaks email forwarding
On 27-Jul-06, at 4:32 PM, Hamish wrote: On Wednesday 26 July 2006 17:25, Marc Perkel wrote: Benny Pedersen wrote: On Tue, July 25, 2006 18:51, Marc Perkel wrote: SPF breaks email forwarding. My users use forwarding. fair, but why not stop using forwarding ? Because my customers want to use forwarding. Perhaps it would be fairer to say that SPF is fine but the forwarding is broken. Forwarding should (IMO) be implemented in such a way as the FORWARDING mailbox should be used as the new return-path (Just like if you forwarded an email from your MUA rather than with the MDA). Then both SPF and forwarding would work fine. And furthermore be consistent. Hamish. That's the basic idea behind SRS. The forwarding server re-writes the header and takes responsibility for the forwarded email. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
On Thu, 27 Jul 2006, Hamish wrote: > Forwarding should (IMO) be implemented in such a way as the > FORWARDING mailbox should be used as the new return-path (Just > like if you forwarded an email from your MUA rather than with the > MDA). Then both SPF and forwarding would work fine. And > furthermore be consistent. ...and lead to a mail loop if the forward-to address starts bounding messages for some reason... -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Windows Genuine Advantage (WGA) means that now you use your computer at the sufferance of Microsoft Corporation. They can kill it remotely without your consent at any time for any reason. --
Re: SPF breaks email forwarding
On Thu, 2006-07-27 at 14:35 -0700, John D. Hardin wrote: > On Thu, 27 Jul 2006, Hamish wrote: > > > Forwarding should (IMO) be implemented in such a way as the > > FORWARDING mailbox should be used as the new return-path (Just > > like if you forwarded an email from your MUA rather than with the > > MDA). Then both SPF and forwarding would work fine. And > > furthermore be consistent. > > ...and lead to a mail loop if the forward-to address starts bounding > messages for some reason... And how does not implementing SRS solve the mail loop problem.
Re: SPF breaks email forwarding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John D. Hardin wrote: > On Thu, 27 Jul 2006, Hamish wrote: > >> Forwarding should (IMO) be implemented in such a way as the >> FORWARDING mailbox should be used as the new return-path (Just >> like if you forwarded an email from your MUA rather than with the >> MDA). Then both SPF and forwarding would work fine. And >> furthermore be consistent. > > ...and lead to a mail loop if the forward-to address starts > bounding messages for some reason... > Which would be resolved in exactly the same way in which mails that already loop is solved (i.e too many hops). (Assuming you don't rewrite <>. You could also add a header to indicate a forwaded email. X-ForwardedFor: and use that for a bounce). Either way existing forwarding is broken. Hamish. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEydHg/3QXwQQkZYwRAhq/AKC586G6dZDmmubAHToCnZ/j0irSlACgqIS6 jKqZTd2wj7NKwuH19Mx0Pr0= =q/0I -END PGP SIGNATURE-
Re: SPF breaks email forwarding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gino Cerullo wrote: > > On 27-Jul-06, at 4:32 PM, Hamish wrote: > >> On Wednesday 26 July 2006 17:25, Marc Perkel wrote: >>> Benny Pedersen wrote: >>>> On Tue, July 25, 2006 18:51, Marc Perkel wrote: >>>>> SPF breaks email forwarding. My users use forwarding. >>>> >>>> fair, but why not stop using forwarding ? >>> >>> Because my customers want to use forwarding. >> >> Perhaps it would be fairer to say that SPF is fine but the >> forwarding is >> broken. >> >> Forwarding should (IMO) be implemented in such a way as the >> FORWARDING mailbox >> should be used as the new return-path (Just like if you forwarded >> an email >> from your MUA rather than with the MDA). Then both SPF and >> forwarding would >> work fine. And furthermore be consistent. >> >> >> Hamish. > > That's the basic idea behind SRS. The forwarding server re-writes > the header and takes responsibility for the forwarded email. > Huh. Fancy that, I never looked at SRS. (But do use SPF and markup on it in SA). (Although not for my home domain because the DNS is with register.com and they don't do TXT records). H -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEydI2/3QXwQQkZYwRAv+5AJsE03rlRqMu2uj1XCG2t3gvtiInPQCg22Pb T/W0uJdLDBZDyOL0Yr6f6cI= =1x8q -END PGP SIGNATURE-
