Re: [courier-users] SPF oddity
Apologies for repeating this question... Is there a way to disable SPF checking on a host by host basis ? --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Sam Varshavchik ha scritto: Alessandro Vesely writes: Currently, the only way that one can concede forwarding is by IP address. That's beside the point. It is a problem. What if the remote host could log in? The bottom line is this. Your email address is [EMAIL PROTECTED] If you need to have example.com forward all your mail to [EMAIL PROTECTED], you'll just have to live with the fact that you can no longer check SPF on received mail. If you still want to check SPF, this still has to be done by example.com. Absolutely agreed. Rewriting the sender's address currently works, but is wrong for backup MXes. Isn't there room for designing a better solution? Your backup MXs should check SPF themselves. Yes, unless for some reason I want to disable SPF checking. That might work with Received-SPF headers, like the BLOCK2 flag does for DNSBLs. (I only do the latter, though.) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable writes: Apologies for repeating this question... Is there a way to disable SPF checking on a host by host basis ? Based on the sender's IP address -- set the BOFH variables in smtpaccess. pgpRnq2UjMpcQ.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Sam Varshavchik wrote: Bowie Bailey writes: Sam Varshavchik wrote: As such, since the whole process is under the complete control of the recipient, the recipient must then recognize that SPF will not be functional on forwarded mail. The recipient must concede to disabling SPF as he cost of having the recipient's mail forwarded. SPF can still be checked, of course, by the forwarder. This assumes that the recipient has control over the destination server. This is frequently not the case. If the recipient has no control over the destination server, then this means that the recipient can't forward mail there. That's the final answer. Not quite true. Forwarding still works if the forwarder rewrites the MAIL FROM address (e.g., to be in the forwarder's own domain). The scheme employed doesn't have to be SRS specifically. Any sender rewriting scheme will do as long as the original sender's SPF record will no longer be violated after rewriting the sender address. I'm not sure whether Courier supports MAIL FROM rewriting, though. signature.asc Description: This is a digitally signed message part. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On 2008-08-27, Sam Varshavchik wrote: Is there a way to disable SPF checking on a host by host basis ? Based on the sender's IP address -- set the BOFH variables in smtpaccess. Thanks Sam, the nearest info I could find is here... http://www.courier-mta.org/couriertcpd.html but I couldn't find an exact example of the syntax, would this be correct ? 192.68.0.1taballow,BOFH --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable writes: On 2008-08-27, Sam Varshavchik wrote: Is there a way to disable SPF checking on a host by host basis ? Based on the sender's IP address -- set the BOFH variables in smtpaccess. Thanks Sam, the nearest info I could find is here... http://www.courier-mta.org/couriertcpd.html but I couldn't find an exact example of the syntax, would this be correct ? 192.68.0.1taballow,BOFH Yes, but the actual variable names aren't BOFH, they're the very same ones that you would set in the bofh configuration file. Basically, the per-ip variables in smtpaccess override the global defaults in the bofh file. pgpKO7vBzjhyR.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Sam Varshavchik wrote: Mail forwarding is not a random event. Mail forwarding occurs, presumably, at the ultimate recipient's request. It is the ultimate recipient that places the forwarding in place, so that the recipient's mail gets forwarded to a different destination. That forwarding recipe includes an email address, which is personally identifiable data and should be under the direct control of its owner. Thus, it makes sense to require some compliance on the sender's side. As such, since the whole process is under the complete control of the recipient, the recipient must then recognize that SPF will not be functional on forwarded mail. The recipient must concede to disabling SPF as the cost of having the recipient's mail forwarded. SPF can still be checked, of course, by the forwarder. Currently, the only way that one can concede forwarding is by IP address. This may make sense for a fully controlled backup MX. In general, the same IP address can be used to forward a message as well as to submit a new one. The forwarded-to recipient has no way to distinguish between those two cases. Furthermore, having to concede full relay privileges to that IP is certainly overkill. Rewriting the sender's address currently works, but is wrong for backup MXes. Isn't there room for designing a better solution? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Alessandro Vesely wrote: Currently, the only way that one can concede forwarding is by IP address. This may make sense for a fully controlled backup MX. In general, the same IP address can be used to forward a message as well as to submit a new one. The forwarded-to recipient has no way to distinguish between those two cases. Furthermore, having to concede full relay privileges to that IP is certainly overkill. Rewriting the sender's address currently works, but is wrong for backup MXes. Isn't there room for designing a better solution? One should always be able to fully trust one's backup MXes, not only for _that_ reason but also because you want them to employ security in a manner _identical_ to your primary MX. If you trust your backup MXes, then you won't have to perform any security checks (including SPF) on mail received from them. IOW, you should always whitelist your backup MXes. signature.asc Description: This is a digitally signed message part. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Alessandro Vesely writes: Currently, the only way that one can concede forwarding is by IP address. That's beside the point. The bottom line is this. Your email address is [EMAIL PROTECTED] If you need to have example.com forward all your mail to [EMAIL PROTECTED], you'll just have to live with the fact that you can no longer check SPF on received mail. If you still want to check SPF, this still has to be done by example.com. If that doesn't work for you, all that means is that you can't forward your mail. That's it. Rewriting the sender's address currently works, but is wrong for backup MXes. Isn't there room for designing a better solution? Your backup MXs should check SPF themselves. pgptxaQYjqXvl.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Sam Varshavchik wrote: Mail forwarding is not a random event. Mail forwarding occurs, presumably, at the ultimate recipient's request. It is the ultimate recipient that places the forwarding in place, so that the recipient's mail gets forwarded to a different destination. As such, since the whole process is under the complete control of the recipient, the recipient must then recognize that SPF will not be functional on forwarded mail. The recipient must concede to disabling SPF as the cost of having the recipient's mail forwarded. SPF can still be checked, of course, by the forwarder. This assumes that the recipient has control over the destination server. This is frequently not the case. I have quite a few of my customers who request that I forward their mail to Hotmail or another generic freemail account. Good luck getting them to cooperate with anything. So far I haven't had any problems with this, but I'm sure it will come up eventually. -- Bowie - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Bowie Bailey writes: Sam Varshavchik wrote: Mail forwarding is not a random event. Mail forwarding occurs, presumably, at the ultimate recipient's request. It is the ultimate recipient that places the forwarding in place, so that the recipient's mail gets forwarded to a different destination. As such, since the whole process is under the complete control of the recipient, the recipient must then recognize that SPF will not be functional on forwarded mail. The recipient must concede to disabling SPF as the cost of having the recipient's mail forwarded. SPF can still be checked, of course, by the forwarder. This assumes that the recipient has control over the destination server. This is frequently not the case. If the recipient has no control over the destination server, then this means that the recipient can't forward mail there. That's the final answer. I have quite a few of my customers who request that I forward their mail to Hotmail or another generic freemail account. Good luck getting them to cooperate with anything. Correct. All of that would factor into the decision as to whether to forward mail, and where. Obviously, since Hotmail checks SPF (I'm fairly sure of that) Hotmail cannot be the destination of forwarded mail. That would be an issue between your customers, and Hotmail, and is none of your concern. So far I haven't had any problems with this, but I'm sure it will come up eventually. Probably. But your only responsibility would be to inform your customers of the details, and explain why forwarding their mail to Hotmail will be unreliable, and there's nothing that you can do about it. You have no influence over Hotmail, and you cannot unilaterally change how SMTP works. As such, you are completely out of the loop, and if they still insist on having their mail forwarded, they'll have to accept the responsibility for it. Presumably, you have the default backscatter suppression setting in place. So, if Hotmail refuses mail delivery, the forwarded mail will be lost completely. pgpl0dGT33oHT.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Julian Mehnle wrote: Alessandro Vesely wrote: Rewriting the sender's address currently works, but is wrong for backup MXes. Isn't there room for designing a better solution? One should always be able to fully trust one's backup MXes, not only for _that_ reason but also because you want them to employ security in a manner _identical_ to your primary MX. If you trust your backup MXes, then you won't have to perform any security checks (including SPF) on mail received from them. IOW, you should always whitelist your backup MXes. The effectiveness of backup MXes originates from topological properties of the network. Thus, setting up backup MXes that way requires maintaining (possibly virtual) boxes with dedicated IPs on different autonomous system. OTOH, there are convenient commercial offers for backup MX services, or ISPs may want to arrange for reciprocal exchange for such services. It may be desirable to provide options for SPF and DNSBL checks, directly configurable by users for each target mailbox. However, lack of standardization makes it hard to set up that stuff. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable wrote: . whitelist forwarder IP addresses . use forwarders that rewrite the sender It is also possible to do both of them. Rather than patching an SRS implementation into Courier, I'd be out to enhance authlib in order to allow easier management of whitelisting: [...] Rewriting the sender should be operated according to sender's local policies, depending on what kind of forwarding is being operated. I guess Sam is correct when he suggests that this ought to be done with maildrop. As usual, I am missing some dots. Perhaps there are 2 situations that need different solutions. I think the above applies to a host that is doing the forwarding in such a way that it will be accepted [...] However, does this mean that there is simply no way, ever, to accept or bypass the SPF block for messages coming into our mailserver from another host that does not rewrite similar forwarded messages? That's exactly the point. The forwarder violates SPF by impersonating someone else. The forwarded message carries no evidence whatsoever that the original message was SPF-compliant, does it? A similar problem arises with DNSBL checking: If you accept forwarded mail from a server that doesn't query the DNSBLs you require, your acceptance policy is broken. Those two problems are common to casual forwarders as well as backup MXes. I don't think that kind of problem can be solved without cooperation between the sending and the receiving hosts. Thus, we are not talking about different solutions, but rather of the two sides of the same solution. However, since cooperation implies agreement, I have no idea how long will it take before any viable solution takes root. In other words, the absolute bottom line is that, if I want to accept messages that are aliased or forwarded from other hosts that do not use SRS or rewrite the From_ header, but do use an SPF TXT record, that I have to disable SPF checking? Yes, at least for that specific host (or backup MX). - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Alessandro Vesely writes: That's exactly the point. The forwarder violates SPF by impersonating someone else. The forwarded message carries no evidence whatsoever that the original message was SPF-compliant, does it? Mail forwarding is not a random event. Mail forwarding occurs, presumably, at the ultimate recipient's request. It is the ultimate recipient that places the forwarding in place, so that the recipient's mail gets forwarded to a different destination. As such, since the whole process is under the complete control of the recipient, the recipient must then recognize that SPF will not be functional on forwarded mail. The recipient must concede to disabling SPF as the cost of having the recipient's mail forwarded. SPF can still be checked, of course, by the forwarder. pgpK4EIJXhuFi.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On 2008-08-24, Alessandro Vesely wrote: In other words, the absolute bottom line is that, if I want to accept messages that are aliased or forwarded from other hosts that do not use SRS or rewrite the From_ header, but do use an SPF TXT record, that I have to disable SPF checking? Yes, at least for that specific host (or backup MX). Thanks for clarifying that. Are you sure or backup MX also applies, because a backup MX does not have local delivery so aliases and forwards won't get expanded until the message hits the target host ? So is there a way to disable SPF checking for a specific host ? This could be a reasonable compromise as I could disable SPF checking for current and important users, that end up forwarding emails to our servers from other hosts, but let our staff know there is a new policy in place that we can no longer accept forwarded addresses from other ISPs. Then I could look into the simplest way to rewrite ~400 .courier files that forward from our server to other ISP servers and retain our usage of both advertising our SPF record(s) and also checking for SPF. --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable wrote: That state of affairs is obviously wrong... Absolutely. A sidebar at http://www.openspf.org/SRS says... [...] if you do check SPF, and you wish to reject messages that fail SPF, then you must do one of two things to avoid rejecting legitimate mail: . whitelist forwarder IP addresses . use forwarders that rewrite the sender It is also possible to do both of them. Rather than patching an SRS implementation into Courier, I'd be out to enhance authlib in order to allow easier management of whitelisting: It would be enough to overload the RELAYCLIENT feature such that after authentication, depending on options, the sender is only allowed to send mail to a given recipient. That way, rather than insert their host's IP into a whitelist, you give their host an id/password pair by which you authorize it to forward to a given mailbox only. The advantages are * long lasting links (no changes required when IPs change,) * single mailbox granularity, which implies * accurate bookkeeping of who is authorized to forward what. That way, the receiving host would have a database of incoming authorizations mirroring the database of forwarding recipes at the senders': A doubly linked list where we now have an unmaintainable singly linked one. Rewriting the sender should be operated according to sender's local policies, depending on what kind of forwarding is being operated. I guess Sam is correct when he suggests that this ought to be done with maildrop. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On Fri, 22 Aug 2008 06:39:37 pm Alessandro Vesely wrote: Mark Constable wrote: That state of affairs is obviously wrong... Absolutely. A sidebar at http://www.openspf.org/SRS says... [...] if you do check SPF, and you wish to reject messages that fail SPF, then you must do one of two things to avoid rejecting legitimate mail: . whitelist forwarder IP addresses . use forwarders that rewrite the sender It is also possible to do both of them. Rather than patching an SRS implementation into Courier, I'd be out to enhance authlib in order to allow easier management of whitelisting: It would be enough to overload the RELAYCLIENT feature such that after authentication, depending on options, the sender is only allowed to send mail to a given recipient. That way, rather than insert their host's IP into a whitelist, you give their host an id/password pair by which you authorize it to forward to a given mailbox only. The advantages are * long lasting links (no changes required when IPs change,) * single mailbox granularity, which implies * accurate bookkeeping of who is authorized to forward what. That way, the receiving host would have a database of incoming authorizations mirroring the database of forwarding recipes at the senders': A doubly linked list where we now have an unmaintainable singly linked one. Rewriting the sender should be operated according to sender's local policies, depending on what kind of forwarding is being operated. I guess Sam is correct when he suggests that this ought to be done with maildrop. As usual, I am missing some dots. Perhaps there are 2 situations that need different solutions. I think the above applies to a host that is doing the forwarding in such a way that it will be accepted by the destination mailserver that employs SPF checking, by rewriting the From_ line. So, for example, every dot courier file that has a [EMAIL PROTECTED] entry needs to apply some maildrop rules to massage the message before it's re-injected back into the system. If that is right then, although it's ugly and I'm not sure exactly how to do it, I can imagine it is feasible. That takes care of me doing the right thing for my users who need to forward messages offsite. However, does this mean that there is simply no way, ever, to accept or bypass the SPF block for messages coming into our mailserver from another host that does not rewrite similar forwarded messages? In other words, the absolute bottom line is that, if I want to accept messages that are aliased or forwarded from other hosts that do not use SRS or rewrite the From_ header, but do use an SPF TXT record, that I have to disable SPF checking? --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable ha scritto: I'm somewhat stunned this has not been more of a noticable problem for anyone using SPF... and that I haven't noticed it myself until now even though we've been using SPF for the past year. Well, it has been the source *many* discussions, and many consider this to be the weakest point of SPF. Actually, it is the weakest point of mail forwarding, see http://en.wikipedia.org/wiki/E-mail_forwarding#Historical_development_of_email_forwarding Trying to make a long story short, * if your business is massive email forwarding, you need SRS to regain control on dynamically building the return-path, which rfc1123 broke, * if someone having access to user's directory manually writes a forwarding recipe, use maildrop and set -f to the recipe writer's or postmaster address, * except when forwarding to the same server: In this case _alias expansion_ (i.e. w/o -f, as opposed to _list expansion_, the two forwarding methods that the SMTP specs provide for) is just fine. That state of affairs is obviously wrong... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On Thu, 21 Aug 2008 06:51:53 pm Alessandro Vesely wrote: Well, it has been the source *many* discussions, and many consider this to be the weakest point of SPF. Actually, it is the weakest point of mail forwarding, see http://en.wikipedia.org/wiki/E-mail_forwarding#Historical_development_of_email_forwarding Excellent link, thank you. Trying to make a long story short, * if your business is massive email forwarding, you need SRS to regain control on dynamically building the return-path, which rfc1123 broke, * if someone having access to user's directory manually writes a forwarding recipe, use maildrop and set -f to the recipe writer's or postmaster address, * except when forwarding to the same server: In this case _alias expansion_ (i.e. w/o -f, as opposed to _list expansion_, the two forwarding methods that the SMTP specs provide for) is just fine. That state of affairs is obviously wrong... Absolutely. A sidebar at http://www.openspf.org/SRS says... RFC 1123 introduced two very convenient but easily abused features: relaying without regard to recipient (open relays) and forwarding without regard to sender. Both features have been abused to the point of unusability. Open relays have been suppressed via blacklisting. SPF stops forwarding without rewriting, but it does so on an opt-in basis. If you, as a recipient do not check SPF, then you can continue to use forwarding without rewriting the sender as before. However, if you do check SPF, and you wish to reject messages that fail SPF, then you must do one of two things to avoid rejecting legitimate mail: . whitelist forwarder IP addresses . use forwarders that rewrite the sender There is a SRS library at http://www.libsrs2.org/ and down the bottom it says Write or maintain patches against MTAs? with courier being mentioned. So... a) if one does not already exist, is anyone interested in a SRS patch for courier based on this (or any other) library ? b) Sam, if such a patch existed, is there any possibility that it could be considered for official inclusion in courier ? --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable writes: On 2008-08-20, Sam Varshavchik wrote: This is the result of me sending a test message to [EMAIL PROTECTED] Aug 20 11:29:02 mail courieresmtpd: started,ip=[:::203.17.154.25] Aug 20 11:29:06 mail courierd: newmsg,id=000BB289.48AB7361.4973: dns; m0.velocity.net.au (mail.velocitynet.com.au [:::203.17.154.25]) Aug 20 11:29:08 mail courieresmtpd: started,ip=[:::203.17.154.25] Aug 20 11:29:16 mail courieresmtpd: error,relay=:::203.17.154.25, from=[EMAIL PROTECTED]: 517 SPF fail [EMAIL PROTECTED]: Address does not pass the Sender Policy Framework As mentioned, I thought a BOFHSPFFROM=mailfromok would cover this situation so can anyone suggest what might be going on here ? mailfromok means that if the SMTP MAIL FROM: address passes SPF, the From: header is not checked. This settings helps SPF work with mailing lists. If a mailing list has its own SPF record, and the list messages carry the mailing list's return address, its valid SPF record validates list messages from senders who have their own SPF records. lists.sourceforge.net has its own SPF record. My mail sent to this list will pass SPF checking even though my domain's SPF record does not include lists.sourceforge.net's IPs. Yep, I think I understand that, thanks. renta.net's SPF record does not seem to include 203.17.154.25, so mailfromok is not in effect. But renta.net's SPF should not have anything to do with 203.17.154.25 as this situation is analogous to a mailing-list at lists.sf.net (kind of). I'm sending an email to [EMAIL PROTECTED] which has a forward back to a user@ on a server I maintain, and the error above is that return email. This is not analogous to lists.sourceforge.net's mailing list. Messages sent to these mailing lists are redistributed with the return address reset back to lists.sourceforge.net. You're not going to get this message with the return address of [EMAIL PROTECTED], but rather with lists.sourceforge.net's own return address. If anyone sends an email to [EMAIL PROTECTED] it gets forwarded to said server and results in the same error so it's simply not possible to add 203.17.154.25 to everyones SPF records. The missing piece is that when the mail gets forwarded, the return address needs to be reset to @jakeman.com.au, and a suitable SPF record needs to be provided. There's actually some semi-standard documentation floating around that sets the standard for rewriting return addresses, when forwarding. However, any address rewriting scheme will work fine. pgp6npcPtBk1x.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On 2008-08-20, Sam Varshavchik wrote: If anyone sends an email to [EMAIL PROTECTED] it gets forwarded to said server and results in the same error so it's simply not possible to add 203.17.154.25 to everyones SPF records. The missing piece is that when the mail gets forwarded, the return address needs to be reset to @jakeman.com.au, and a suitable SPF record needs to be provided. There's actually some semi-standard documentation floating around that sets the standard for rewriting return addresses, when forwarding. However, any address rewriting scheme will work fine. Wow, I just did a test between 2 courier mailservers and the same problem occurs. I created a simple .courier-test on a neighboring courier mailserver that forwards back to me and sent a test message and, sure enough, it got blocked for the same reason... Aug 21 15:18:23 mail courieresmtpd: error,relay=:::202.6.xxx.xxx, from=[EMAIL PROTECTED]: 517 SPF fail [EMAIL PROTECTED]: Address does not pass the Sender Policy Framework so if anyone sends an email to this particular alias then all messages are going to be blocked for the same reason that everyone elses domain cannot possibly be added to the 202.6.xxx.xxx (in this case) domains SPF record. I would imagine this is a common functionality, to simply set up a forwarding alias to another email address, but if the destination mailserver happens to use SPF checking then all messages will be blocked. I'm somewhat stunned this has not been more of a noticable problem for anyone using SPF... and that I haven't noticed it myself until now even though we've been using SPF for the past year. Now, I can probably locate that semi-standard documentation floating around and make sure my local aliases have rewritten return addresses (presumably) but I can't do anything about other mailservers that I have no control over, as per the original issue illustrated in this thread. Am I reading this right and are there any other solutions aside from disabling and adbandoning the use of SPF altogether ? --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On Mon, 18 Aug 2008 09:01:28 pm Sam Varshavchik wrote: Because it's the From: address that fails it: jakeman.com.au. 3568IN TXT v=spf1 a ~all jakeman.com.au. 3550IN A 203.129.33.155 I'm now confused with a related issue where there is an alias at the above domains mailserver that forwards back to us but we reject it with a 517. I thought using mailfromok would fix situations like this (mailing list redirects etc). # dig +short txt jakeman.com.au. v=spf1 ip4:203.17.154.25 mx ~all # grep SPF /etc/courier/bofh opt BOFHSPFHELO=pass,unknown,error,none,neutral opt BOFHSPFMAILFROM=pass,unknown,error,none,neutral opt BOFHSPFFROM=pass,unknown,error,none,neutral,mailfromok opt BOFHSPFTRUSTME=1 This is the result of me sending a test message to [EMAIL PROTECTED] Aug 20 11:29:02 mail courieresmtpd: started,ip=[:::203.17.154.25] Aug 20 11:29:06 mail courierd: newmsg,id=000BB289.48AB7361.4973: dns; m0.velocity.net.au (mail.velocitynet.com.au [:::203.17.154.25]) Aug 20 11:29:08 mail courieresmtpd: started,ip=[:::203.17.154.25] Aug 20 11:29:16 mail courieresmtpd: error,relay=:::203.17.154.25, from=[EMAIL PROTECTED]: 517 SPF fail [EMAIL PROTECTED]: Address does not pass the Sender Policy Framework As mentioned, I thought a BOFHSPFFROM=mailfromok would cover this situation so can anyone suggest what might be going on here ? *** Also, some googling indicates these 502s can be ignored, is that true? Aug 20 11:29:16 mail courieresmtpd: error,relay=:::203.17.154.25, msg=502 ESMTP command error,cmd: RCPT TO:x ORCPT=rfc822;x Aug 20 11:29:32 mail courieresmtpd: error,relay=:::203.17.154.25, msg=502 ESMTP command error,cmd: DATA --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On 2008-08-20, Sam Varshavchik wrote: This is the result of me sending a test message to [EMAIL PROTECTED] Aug 20 11:29:02 mail courieresmtpd: started,ip=[:::203.17.154.25] Aug 20 11:29:06 mail courierd: newmsg,id=000BB289.48AB7361.4973: dns; m0.velocity.net.au (mail.velocitynet.com.au [:::203.17.154.25]) Aug 20 11:29:08 mail courieresmtpd: started,ip=[:::203.17.154.25] Aug 20 11:29:16 mail courieresmtpd: error,relay=:::203.17.154.25, from=[EMAIL PROTECTED]: 517 SPF fail [EMAIL PROTECTED]: Address does not pass the Sender Policy Framework As mentioned, I thought a BOFHSPFFROM=mailfromok would cover this situation so can anyone suggest what might be going on here ? mailfromok means that if the SMTP MAIL FROM: address passes SPF, the From: header is not checked. This settings helps SPF work with mailing lists. If a mailing list has its own SPF record, and the list messages carry the mailing list's return address, its valid SPF record validates list messages from senders who have their own SPF records. lists.sourceforge.net has its own SPF record. My mail sent to this list will pass SPF checking even though my domain's SPF record does not include lists.sourceforge.net's IPs. Yep, I think I understand that, thanks. renta.net's SPF record does not seem to include 203.17.154.25, so mailfromok is not in effect. But renta.net's SPF should not have anything to do with 203.17.154.25 as this situation is analogous to a mailing-list at lists.sf.net (kind of). I'm sending an email to [EMAIL PROTECTED] which has a forward back to a user@ on a server I maintain, and the error above is that return email. If anyone sends an email to [EMAIL PROTECTED] it gets forwarded to said server and results in the same error so it's simply not possible to add 203.17.154.25 to everyones SPF records. I understand if I added that IP to renta.net's SPF record then it would most likely work, but only for me in this case, but I can't do that for other people sending to [EMAIL PROTECTED] Mail sent directly from [EMAIL PROTECTED] to our server works okay, now that they have updated their jakeman.com.au SPF record. FWIW, the remote server is 220 m0.velocity.net.au ESMTP Postfix (I thought it may have perhaps been some dud windows exchange server) --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
Mark Constable writes: From what I understand about SPF, this example should have been delivered to our mailserver but was rejected. Perhaps someone here can pick up on why it wasn't... Aug 18 09:56:22 mail courieresmtpd: error,relay=:::203.17.154.25, from=[EMAIL PROTECTED]: 517 SPF softfail [EMAIL PROTECTED]: Address does not pass the Sender Policy Framework Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=HELO; sender=m0.velocity.net.au; remoteip=:::203.17.154.25; remotehost=mail.velocitynet.com.au; helo=m0.velocity.net.au; receiver=mail.spiderweb.com.au; Received-SPF: neutral (Address does not pass the Sender Policy Framework) SPF=MAILFROM; [EMAIL PROTECTED]; remoteip=:::203.17.154.25; remotehost=mail.velocitynet.com.au; helo=m0.velocity.net.au; receiver=mail.spiderweb.com.au; # dig +short a m0.velocity.net.au. 203.17.154.25 # dig +short a mail.velocitynet.com.au. 203.17.154.25 # dig +short txt velocity.net.au. v=spf1 a mx include:velocitynet.com.au ~all # dig +short txt velocitynet.com.au. v=spf1 mx ip4:203.17.154.25 a:server.kgroup.com.au ~all # grep SPF /etc/courier/bofh opt BOFHSPFHELO=pass,unknown,error,none,neutral opt BOFHSPFMAILFROM=pass,unknown,error,none,neutral opt BOFHSPFFROM=pass,unknown,error,none,neutral,mailfromok opt BOFHSPFTRUSTME=1 To me, regardless of whether velocity.net.au or velocitynet.com.au is the sending domain, the sending domains txt record should cover it. Is it possible that courier is not respecting the include ? Or, can anyone see why this isn't working ? Because it's the From: address that fails it: jakeman.com.au. 3568IN TXT v=spf1 a ~all jakeman.com.au. 3550IN A 203.129.33.155 pgproniuiDOW0.pgp Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] SPF oddity
On Mon, 18 Aug 2008 09:01:28 pm Sam Varshavchik wrote: Because it's the From: address that fails it: jakeman.com.au. 3568IN TXT v=spf1 a ~all jakeman.com.au. 3550IN A 203.129.33.155 On Mon, 18 Aug 2008 08:52:59 pm Kristian Duus Østergaard wrote: You are looking in the wrong place $ dig +short txt jakeman.com.au v=spf1 a ~all I think this will work better if you make this the TXT field for jakeman.com.au : v=spf1 a:mail.velocitynet.com.au ~all Thank you Sam and Kristian, it's so obvious now you point it out. Sorry about the noise. --markc - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
