Re: regex: chars to escape bsides @
Am 05.01.2015 um 22:13 schrieb John Hardin:
On Mon, 5 Jan 2015, Bowie Bailey wrote:
You can avoid having to escape the slash (/) by using a different
separator for the regex. This can avoid leaning toothpick syndrome.
For example:
m#http://match/this/url/#
Ouch. # won't work for that (in SA at least) as it comments out the rest
of the RE.
which means # needs to be escaped too... thanks!
[harry@srv-rhsoft:~]$ php -r 'echo preg_quote(#);'
#
function sa_quote($input)
{
$input = str_replace(array(\n, \r, \0), '', trim($input));
$input = str_replace(\t, ' ', $input);
$input = preg_quote($input);
$input = str_replace('/', '\/', $input);
$input = str_replace('@', '\@', $input);
$input = str_replace('%', '\%', $input);
$input = str_replace('#', '\#', $input);
return $input;
}
signature.asc
Description: OpenPGP digital signature
Re: regex: chars to escape bsides @
On 1/5/2015 4:13 PM, John Hardin wrote: On Mon, 5 Jan 2015, Bowie Bailey wrote: You can avoid having to escape the slash (/) by using a different separator for the regex. This can avoid leaning toothpick syndrome. For example: m#http://match/this/url/# Ouch. # won't work for that (in SA at least) as it comments out the rest of the RE. Ack! Forgot about that minor difference with SA. # is my general go-to character for that in normal Perl scripts. This should illustrate the same point with the minor improvement of actually *working* in SA: m^http://match/this/url/^ -- Bowie
Re: SPF_HELO_PASS,SPF_NONE
Am 05.01.2015 um 23:07 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 22:58: well, the sender don't publish SPF at all helo is not a spf policy, its a spf helo policy, confused ?, me 2 :=) without a SPF record a domain don't have anything but SPF_NONE dig duggi.junc.org txt dig junc.org txt see not one spf txt, but 2 hope that covers it for others aswell so what - the domain and the subdomain publish SPF as example whoe...@domaintechnik.at don't and hence there is no justification for hit score SPF_HELO_PASS -0.001 duggi.junc.org. 3597IN TXT v=spf1 a -all junc.org. 3600IN TXT v=spf1 ip4:80.162.68.52/30 -all @domaintechnik.at don't publish SPF regardless over what server it was sent and so i see no valid reason for a positive score of outgoing mails over host5.ssl-gesichert.at[213.145.228.32] signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
On Mon, 05 Jan 2015 22:58:55 +0100 Reindl Harald wrote: Am 05.01.2015 um 22:54 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 18:52: how can SPF_HELO_PASS,SPF_NONE fire both? the above is 2 diff tests i know that by myself *but* if the sending domain does not publish any SPF policy then there should be no positive score for SPF_HELO_PASS It doesn't have a positive score: score SPF_HELO_PASS -0.001
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-05 18:52: how can SPF_HELO_PASS,SPF_NONE fire both? the above is 2 diff tests
Re: regex: chars to escape bsides @
Am 05.01.2015 um 22:57 schrieb Bowie Bailey: On 1/5/2015 4:13 PM, John Hardin wrote: On Mon, 5 Jan 2015, Bowie Bailey wrote: You can avoid having to escape the slash (/) by using a different separator for the regex. This can avoid leaning toothpick syndrome. For example: m#http://match/this/url/# Ouch. # won't work for that (in SA at least) as it comments out the rest of the RE. Ack! Forgot about that minor difference with SA. # is my general go-to character for that in normal Perl scripts. This should illustrate the same point with the minor improvement of actually *working* in SA: m^http://match/this/url/^ i would not play such games because it makes it even more likely that a common escape function is missing something, besides that headerCUST_MANY_SPAM_TO X-Local-Envelope-To =~ /^(\h\.reindl\@thelounge\.net\)$/i signature.asc Description: OpenPGP digital signature
Re: regex: chars to escape bsides @
Am 05.01.2015 um 23:14 schrieb Bowie Bailey:
On 1/5/2015 5:02 PM, Reindl Harald wrote:
Am 05.01.2015 um 22:57 schrieb Bowie Bailey:
On 1/5/2015 4:13 PM, John Hardin wrote:
For example:
m#http://match/this/url/#
Ouch. # won't work for that (in SA at least) as it comments out the
rest of the RE.
Ack! Forgot about that minor difference with SA. # is my general go-to
character for that in normal Perl scripts.
This should illustrate the same point with the minor improvement of
actually *working* in SA:
m^http://match/this/url/^
i would not play such games because it makes it even more likely that
a common escape function is missing something, besides that
headerCUST_MANY_SPAM_TO X-Local-Envelope-To =~
/^(\h\.reindl\@thelounge\.net\)$/i
It is mainly useful for creating a regex to match a URI without needing
to escape every slash in the string. Trying to sort out something like:
/http:\/\/domain\.com\/xxx\/blah\/blah\// gets old fast. So you pick a
character that you don't need in the regex and use it as a separator
character instead so you don't need nearly as many escapes.
agreed but normally one would use a common escape function and that
becomes complicated if you have to escape different chars here and there
Now that I think about it, there is at least one other character that
needs escaping in a regex: the pipe symbol |
well, that's luckily covered, i only did not expect that i need to
handle @ % and # manually especially because @ does not need to be
escaped for grep or postfix-pcre rules
[harry@srv-rhsoft:~]$ php -r echo preg_quote('|');
\|
signature.asc
Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-05 23:13: Am 05.01.2015 um 23:07 schrieb Benny Pedersen: @domaintechnik.at don't publish SPF regardless over what server it was sent and so i see no valid reason for a positive score of outgoing mails over host5.ssl-gesichert.at[213.145.228.32] helo is mta, domain is domain owner a single ip can have more then one domain, domain in mta can be diffrent helo domain then envelope from have you got it now ?
Re: regex: chars to escape bsides @
On Mon, 2015-01-05 at 13:13 -0800, John Hardin wrote: Ouch. # won't work for that (in SA at least) as it comments out the rest of the RE. But at least you can escape the # if you need it in a regex. Martin
Re: SPF_HELO_PASS,SPF_NONE
Am 05.01.2015 um 22:54 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 18:52: how can SPF_HELO_PASS,SPF_NONE fire both? the above is 2 diff tests i know that by myself *but* if the sending domain does not publish any SPF policy then there should be no positive score for SPF_HELO_PASS because take the HELO into account si in general questionable and, well, the sender don't publish SPF at all signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-05 22:58: well, the sender don't publish SPF at all helo is not a spf policy, its a spf helo policy, confused ?, me 2 :=) dig duggi.junc.org txt dig junc.org txt see not one spf txt, but 2 hope that covers it for others aswell
Re: regex: chars to escape bsides @
On 1/5/2015 5:02 PM, Reindl Harald wrote: Am 05.01.2015 um 22:57 schrieb Bowie Bailey: On 1/5/2015 4:13 PM, John Hardin wrote: On Mon, 5 Jan 2015, Bowie Bailey wrote: You can avoid having to escape the slash (/) by using a different separator for the regex. This can avoid leaning toothpick syndrome. For example: m#http://match/this/url/# Ouch. # won't work for that (in SA at least) as it comments out the rest of the RE. Ack! Forgot about that minor difference with SA. # is my general go-to character for that in normal Perl scripts. This should illustrate the same point with the minor improvement of actually *working* in SA: m^http://match/this/url/^ i would not play such games because it makes it even more likely that a common escape function is missing something, besides that headerCUST_MANY_SPAM_TO X-Local-Envelope-To =~ /^(\h\.reindl\@thelounge\.net\)$/i It is mainly useful for creating a regex to match a URI without needing to escape every slash in the string. Trying to sort out something like: /http:\/\/domain\.com\/xxx\/blah\/blah\// gets old fast. So you pick a character that you don't need in the regex and use it as a separator character instead so you don't need nearly as many escapes. Now that I think about it, there is at least one other character that needs escaping in a regex: the pipe symbol |. -- Bowie
RE: SPF_HELO_PASS,SPF_NONE
without a SPF record a domain don't have anything but SPF_NONE Doesn't that depend on the HELO of the server? If they HELO'd with another name which does have a record it would explain it. (pure speculation, in your posts I didn't see where they HELO'd with, or I have missed it). SPF_HELO_PASS has nothing to do with the sending domain, but with the name the incoming mailserver identifies itself with HELO in the initial connection, (which can be really anything but should be valid and preferably their own hostname). Can you dig up the HELO/EHLO from your logfiles or from the headers of the mail in question? /MJ -Oorspronkelijk bericht- Van: Reindl Harald [mailto:h.rei...@thelounge.net] Verzonden: maandag 5 januari 2015 23:13 Aan: users@spamassassin.apache.org Onderwerp: Re: SPF_HELO_PASS,SPF_NONE
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 00:06 schrieb RW: On Mon, 05 Jan 2015 22:58:55 +0100 Reindl Harald wrote: Am 05.01.2015 um 22:54 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 18:52: how can SPF_HELO_PASS,SPF_NONE fire both? the above is 2 diff tests i know that by myself *but* if the sending domain does not publish any SPF policy then there should be no positive score for SPF_HELO_PASS It doesn't have a positive score: score SPF_HELO_PASS -0.001 that is a positive score in context of less spam probability just because somebody sends a HELO command - frankly all day long zombies send HELO commands of known domains up to fake PTR's if the envelope domain don't push a SPF policy *only* NO_SPF should hit however, fixed that in local.cf meta __SPF_FULL_PASS 0 meta __SPF_RANDOM_SENDER 0 score SPF_HELO_PASS 0 score SPF_HELO_FAIL 0 score SPF_HELO_SOFTFAIL 0 score SPF_NONE 0.05 score SPF_PASS -0.05 score SPF_SOFTFAIL 1.5 score SPF_FAIL 2.5 signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 02:38 schrieb Derek Diget: On Tue, 6 Jan 2015 at 00:46 +0100, Reindl Harald wrote: =Am 06.01.2015 um 00:06 schrieb RW: = On Mon, 05 Jan 2015 22:58:55 +0100 = Reindl Harald wrote: = Am 05.01.2015 um 22:54 schrieb Benny Pedersen: = Reindl Harald skrev den 2015-01-05 18:52: =how can SPF_HELO_PASS,SPF_NONE fire both? = = the above is 2 diff tests = = i know that by myself *but* if the sending domain does not publish = any SPF policy then there should be no positive score for = SPF_HELO_PASS = = It doesn't have a positive score: = = score SPF_HELO_PASS -0.001 = =that is a positive score in context of less spam probability just because =somebody sends a HELO command - frankly all day long zombies send HELO =commands of known domains up to fake PTR's What does (not) having a SPF record and passing or failing have anything to do whether a message is spam or not? did i say that? i just said what i wrote in the subject is impossible at the same time SPF has to do with sender policy and is an anti-forgery tool. It is not a anti-spam tool. (A forged message may equal spam to most people, but a spam message does not always equal a forged message.) Similar idea with DKIM. Both allow the domain owner to assert ownership of a particular mail flow, but doesn't say ANYTHING about the domain owner. Again, how much spam mail passes both SPF and DKIM tests? Where SPF/DKIM enter into anti-spam is they tie an domain owner to mail flows such that a reputation system can build built. i know that all Not sure about your mail flow, but we get LOTs of spam that passes (one or both) SPF checks. which has nothing to do with the topic =if the envelope domain don't push a SPF policy *only* NO_SPF should hit And back to the original question in postsee http://www.openspf.org/FAQ/Common_mistakes#helo To publish/not publish and what to publish in an SPF record discussion should probably be moved to spf-discuss or spf-help at http://www.openspf.org/Forums NO it should not because i talk about which *spamassassin rules* hit and why it is wrong - not mor, not less - the sending domain don't publish any SPF record signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
On Tue, 6 Jan 2015, Reindl Harald wrote: Am 06.01.2015 um 02:27 schrieb John Hardin: On Tue, 6 Jan 2015, Reindl Harald wrote: it's a matter of technical correctness no SPF on the envelope domain, no SPF * OK:SPF_PASS * OK:SPF_PASS,SPF_HELO_PASS * OK:SPF_NONE * WRONG: SPF_NONE,SPF_HELO_PASS one can argue about the severity but the correctness is out of question Are you assuming that the MTA will always be in the same domain as the envelope sender address when you say that? no - why should i? we host 600 domains on the same MTA i only say there can not be any sort of SPF PASS if the sending domain don't have any SPF record at all - it's just wrong And if the MTA's domain, which is in a different domain than the envelope sender, *does* have an SPF record, and the MTA is valid per that SPF record? Are you saying the SPF for the MTA/HELO domain should not be checked at all if it is different than the envelope sender domain? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- An entitlement beneficiary is a person or special interest group who didn't earn your money, but demands the right to take your money because they *want* it.-- John McKay, _The Welfare State: No Mercy for the Middle Class_ --- 12 days until Benjamin Franklin's 309th Birthday
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-06 01:31: my whole point is when the sending domain don't have a SPF record and so SPF_NONE correctly hits all meta-rules in context of SPF should not fire up at all its irrelevant since helo testing and envelope from is diffrence tests there is no dependice even
Re: SPF_HELO_PASS,SPF_NONE
On Mon, 05 Jan 2015 23:13:15 +0100 Reindl Harald wrote: so what - the domain and the subdomain publish SPF as example whoe...@domaintechnik.at don't and hence there is no justification for hit score SPF_HELO_PASS -0.001 Ah, when I previously pointed out that it didn't have a positive score I assumed you must have a custom score. If you mean why does it have a non-zero score then the reason is that -0.001 and 0.001 are the standard nominal scores assigned to informational rules. @domaintechnik.at don't publish SPF regardless over what server it was sent and so i see no valid reason for a positive score of outgoing mails over host5.ssl-gesichert.at[213.145.228.32]
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 00:10 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 23:13: Am 05.01.2015 um 23:07 schrieb Benny Pedersen: @domaintechnik.at don't publish SPF regardless over what server it was sent and so i see no valid reason for a positive score of outgoing mails over host5.ssl-gesichert.at[213.145.228.32] helo is mta, domain is domain owner a single ip can have more then one domain, domain in mta can be diffrent helo domain then envelope from have you got it now? Benny i got more then you imagine after maintain some hundret domains for over a decade from registry level over DNS to email and webservices, please get out of my sight signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-06 00:41: Benny i got more then you imagine after maintain some hundret domains for over a decade from registry level over DNS to email and webservices, please get out of my sight fair, helo is more important in spf mta checkers then in sa spf checkers but the possible faked helo mta can be tested without spf since mta can distinct client ips and helo names in a hash table
Re: SPF_HELO_PASS,SPF_NONE
On Tue, 06 Jan 2015 00:46:18 +0100 Reindl Harald wrote: Am 06.01.2015 um 00:06 schrieb RW: On Mon, 05 Jan 2015 22:58:55 +0100 Reindl Harald wrote: Am 05.01.2015 um 22:54 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 18:52: how can SPF_HELO_PASS,SPF_NONE fire both? the above is 2 diff tests i know that by myself *but* if the sending domain does not publish any SPF policy then there should be no positive score for SPF_HELO_PASS It doesn't have a positive score: score SPF_HELO_PASS -0.001 that is a positive score in context of less spam probability just because somebody sends a HELO command - frankly all day long zombies send HELO commands of known domains up to fake PTR's if the envelope domain don't push a SPF policy *only* NO_SPF should hit As I pointed-out the -0.001 is a nominal score assigned to informational rules. The point of helo tests is when they fail. If a compromised host is telling you it's not permitted to send email then what does it matter if the (probably spoofed) envelope domain doesn't have an SPF policy.
Re: regex: chars to escape bsides @
On Mon, 5 Jan 2015, Bowie Bailey wrote: On 1/5/2015 4:13 PM, John Hardin wrote: On Mon, 5 Jan 2015, Bowie Bailey wrote: You can avoid having to escape the slash (/) by using a different separator for the regex. This can avoid leaning toothpick syndrome. For example: m#http://match/this/url/# Ouch. # won't work for that (in SA at least) as it comments out the rest of the RE. Ack! Forgot about that minor difference with SA. # is my general go-to character for that in normal Perl scripts. This should illustrate the same point with the minor improvement of actually *working* in SA: m^http://match/this/url/^ I tend to avoid using symbols that are syntactically significant in REs for that purpose. In your example, you can't then anchor the RE at the beginning of the URL because ^ has been repurposed as the RE delimiter. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The social contract exists so that everyone doesn't have to squat in the dust holding a spear to protect his woman and his meat all day every day. It does not exist so that the government can take your spear, your meat, and your woman because it knows better what to do with them. -- Dagny @ Ace of Spades --- 12 days until Benjamin Franklin's 309th Birthday
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 02:27 schrieb John Hardin: On Tue, 6 Jan 2015, Reindl Harald wrote: it's a matter of technical correctness no SPF on the envelope domain, no SPF * OK:SPF_PASS * OK:SPF_PASS,SPF_HELO_PASS * OK:SPF_NONE * WRONG: SPF_NONE,SPF_HELO_PASS one can argue about the severity but the correctness is out of question Are you assuming that the MTA will always be in the same domain as the envelope sender address when you say that? no - why should i? we host 600 domains on the same MTA i only say there can not be any sort of SPF PASS if the sending domain don't have any SPF record at all - it's just wrong signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 03:00 schrieb John Hardin: On Tue, 6 Jan 2015, Reindl Harald wrote: Am 06.01.2015 um 02:27 schrieb John Hardin: On Tue, 6 Jan 2015, Reindl Harald wrote: it's a matter of technical correctness no SPF on the envelope domain, no SPF * OK:SPF_PASS * OK:SPF_PASS,SPF_HELO_PASS * OK:SPF_NONE * WRONG: SPF_NONE,SPF_HELO_PASS one can argue about the severity but the correctness is out of question Are you assuming that the MTA will always be in the same domain as the envelope sender address when you say that? no - why should i? we host 600 domains on the same MTA i only say there can not be any sort of SPF PASS if the sending domain don't have any SPF record at all - it's just wrong And if the MTA's domain, which is in a different domain than the envelope sender, *does* have an SPF record, and the MTA is valid per that SPF record? that don't say anything about the incoming mail because of it's envelope sender with no SPF record - why? there is no connection between the hosts SPF and the envelope senders until the envelope publish SPF for his domain and lists that server there Are you saying the SPF for the MTA/HELO domain should not be checked at all if it is different than the envelope sender domain? not in context of SPF in that case you typically look if the HELO name exists at all and matches but you need to be careful because way too much servers use localhost.localdomain because a sloppy setup or a hostname from their internal DNS zone not existing on the WAN (even with the same domain) and hence things like http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname are asking for trouble (been there) signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 01:27 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-06 00:41: Benny i got more then you imagine after maintain some hundret domains for over a decade from registry level over DNS to email and webservices, please get out of my sight fair, helo is more important in spf mta checkers then in sa spf checkers but the possible faked helo mta can be tested without spf since mta can distinct client ips and helo names in a hash table my whole point is when the sending domain don't have a SPF record and so SPF_NONE correctly hits all meta-rules in context of SPF should not fire up at all signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 01:32 schrieb RW: On Tue, 06 Jan 2015 00:46:18 +0100 Reindl Harald wrote: Am 06.01.2015 um 00:06 schrieb RW: On Mon, 05 Jan 2015 22:58:55 +0100 Reindl Harald wrote: Am 05.01.2015 um 22:54 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-05 18:52: how can SPF_HELO_PASS,SPF_NONE fire both? the above is 2 diff tests i know that by myself *but* if the sending domain does not publish any SPF policy then there should be no positive score for SPF_HELO_PASS It doesn't have a positive score: score SPF_HELO_PASS -0.001 that is a positive score in context of less spam probability just because somebody sends a HELO command - frankly all day long zombies send HELO commands of known domains up to fake PTR's if the envelope domain don't push a SPF policy *only* NO_SPF should hit As I pointed-out the -0.001 is a nominal score assigned to informational rules yes and no, having 10 wrong informational hits and you are at -0.01 and may make the difference between tag-level or not The point of helo tests is when they fail. If a compromised host is telling you it's not permitted to send email then what does it matter if the (probably spoofed) envelope domain doesn't have an SPF policy it's a matter of technical correctness no SPF on the envelope domain, no SPF * OK:SPF_PASS * OK:SPF_PASS,SPF_HELO_PASS * OK:SPF_NONE * WRONG: SPF_NONE,SPF_HELO_PASS one can argue about the severity but the correctness is out of question signature.asc Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
On Tue, 6 Jan 2015, Reindl Harald wrote: it's a matter of technical correctness no SPF on the envelope domain, no SPF * OK:SPF_PASS * OK:SPF_PASS,SPF_HELO_PASS * OK:SPF_NONE * WRONG: SPF_NONE,SPF_HELO_PASS one can argue about the severity but the correctness is out of question Are you assuming that the MTA will always be in the same domain as the envelope sender address when you say that? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- An entitlement beneficiary is a person or special interest group who didn't earn your money, but demands the right to take your money because they *want* it.-- John McKay, _The Welfare State: No Mercy for the Middle Class_ --- 12 days until Benjamin Franklin's 309th Birthday
Re: SPF_HELO_PASS,SPF_NONE
On Tue, 6 Jan 2015 at 00:46 +0100, Reindl Harald wrote: =Am 06.01.2015 um 00:06 schrieb RW: = On Mon, 05 Jan 2015 22:58:55 +0100 = Reindl Harald wrote: = Am 05.01.2015 um 22:54 schrieb Benny Pedersen: = Reindl Harald skrev den 2015-01-05 18:52: =how can SPF_HELO_PASS,SPF_NONE fire both? = = the above is 2 diff tests = = i know that by myself *but* if the sending domain does not publish = any SPF policy then there should be no positive score for = SPF_HELO_PASS = = It doesn't have a positive score: = = score SPF_HELO_PASS -0.001 = =that is a positive score in context of less spam probability just because =somebody sends a HELO command - frankly all day long zombies send HELO =commands of known domains up to fake PTR's What does (not) having a SPF record and passing or failing have anything to do whether a message is spam or not? SPF has to do with sender policy and is an anti-forgery tool. It is not a anti-spam tool. (A forged message may equal spam to most people, but a spam message does not always equal a forged message.) Similar idea with DKIM. Both allow the domain owner to assert ownership of a particular mail flow, but doesn't say ANYTHING about the domain owner. Again, how much spam mail passes both SPF and DKIM tests? Where SPF/DKIM enter into anti-spam is they tie an domain owner to mail flows such that a reputation system can build built. Not sure about your mail flow, but we get LOTs of spam that passes (one or both) SPF checks. =if the envelope domain don't push a SPF policy *only* NO_SPF should hit And back to the original question in postsee http://www.openspf.org/FAQ/Common_mistakes#helo To publish/not publish and what to publish in an SPF record discussion should probably be moved to spf-discuss or spf-help at http://www.openspf.org/Forums. -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-06 01:55: * OK:SPF_PASS * OK:SPF_PASS,SPF_HELO_PASS meta SPF_FULL_PASS (SPF_PASS SPF_HELO_PASS) score as you like * OK:SPF_NONE * WRONG: SPF_NONE,SPF_HELO_PASS meta SPF_FULL_FAIL (!SPF_PASS SPF_HELO_PASS) score as you like one can argue about the severity but the correctness is out of question well its opensource, it might not be a good test anyway
Re: SPF_HELO_PASS,SPF_NONE
Reindl Harald skrev den 2015-01-06 02:45: i only say there can not be any sort of SPF PASS if the sending domain don't have any SPF record at all - it's just wrong you dont get it :( sending domain is not in helo ! giving up :(
Re: SPF_HELO_PASS,SPF_NONE
Am 06.01.2015 um 03:25 schrieb Benny Pedersen: Reindl Harald skrev den 2015-01-06 02:45: i only say there can not be any sort of SPF PASS if the sending domain don't have any SPF record at all - it's just wrong you dont get it :( sending domain is not in helo ! giving up :( you don't get it if the envelope-domain has no SPF published and want to verify anything in context of HELO then you can check: * does the HELO hostname exist at all * does the IP match in both directions but you are far away from a SPF_HELO_PASS in context of the incoming mail, frankly it's wrong and unrelated until the envelope sender is not @helo-hostname signature.asc Description: OpenPGP digital signature
Re: regex: chars to escape bsides @
--As of January 5, 2015 4:38:03 PM -0800, John Hardin is alleged to have
said:
On Mon, 5 Jan 2015, Bowie Bailey wrote:
On 1/5/2015 4:13 PM, John Hardin wrote:
On Mon, 5 Jan 2015, Bowie Bailey wrote:
You can avoid having to escape the slash (/) by using a different
separator for the regex. This can avoid leaning toothpick
syndrome.
For example:
m#http://match/this/url/#
Ouch. # won't work for that (in SA at least) as it comments out the
rest of the RE.
Ack! Forgot about that minor difference with SA. # is my general go-to
character for that in normal Perl scripts.
This should illustrate the same point with the minor improvement of
actually *working* in SA:
m^http://match/this/url/^
I tend to avoid using symbols that are syntactically significant in REs
for that purpose. In your example, you can't then anchor the RE at the
beginning of the URL because ^ has been repurposed as the RE delimiter.
--As for the rest, it is mine.
Since we've already established this is Perl...
I like to use braces. Perl handles them (and brackets or parens)
specially: Open with the opening brace and you close with the closing
brace. I think Perl will parse for balance as well, but I haven't checked
at the moment.
m{http://match/this/url}
In general though I do tend to stick with slashes unless it's going to be a
problem; it's just more common and easier for people to recognize.
Daniel T. Staal
---
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---
Re: SPF_HELO_PASS,SPF_NONE
On 2015-01-05 18:34, Reindl Harald wrote: if the envelope-domain has no SPF published and want to verify anything in context of HELO then you can check: * does the HELO hostname exist at all * does the IP match in both directions but you are far away from a SPF_HELO_PASS in context of the incoming mail, frankly it's wrong and unrelated until the envelope sender is not @helo-hostname You might want to give the SPF specs another read, SPF can optionally apply to the HELO/EHLO field. https://tools.ietf.org/html/rfc7208#section-2.3, which reads in part: It is RECOMMENDED that SPF verifiers not only check the MAIL FROM identity but also separately check the HELO identity by applying the check_host() function (Section 4 https://tools.ietf.org/html/rfc7208#section-4) to the HELO identity as the sender. Since this applies to the HELO/EHLO field separately from the MAIL FROM based checks, it is perfectly valid to have a SPF_HELO_PASS even if the sending domain has no SPF policy. This is normal and expected behaviour. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren
SPF_HELO_PASS,SPF_NONE
how can SPF_HELO_PASS,SPF_NONE fire both? signature.asc Description: OpenPGP digital signature
Re: regex: chars to escape bsides @
On 1/4/2015 5:42 AM, Reindl Harald wrote:
Am 04.01.2015 um 06:43 schrieb Bob Proulx:
The additional issue was that you were referencing PHP documentation.
Might as well have been referencing Lisp documentation for all of the
relevance it had. That was the point I saw being addressed at that
point. PHP is a similar syntax that came after Perl but it very much
is its own thing and Perl does not derive from it
we are talking about PCRE and the PHP function preg_quote() to escape
a string for *perl* regular expressions not the language syntax and
since the backneds are alreay there i just asked *what* chars
*additional* to that function needs to be escaped *besides* the @ i
found out myself
that is a short and simple question and not refer to the used PHP
function would not have been hepful at all
Ok. Here is an attempt at a simple answer off the top of my head. (Not
guaranteed to be complete)
The following characters may need to be escaped in a Perl regex (as used
in SA) if intended to be used as literal characters:
$%@/[{*+?\
] and } may need to be escaped as well, but I don't think it is required.
You can avoid having to escape the slash (/) by using a different
separator for the regex. This can avoid leaning toothpick syndrome.
For example:
m#http://match/this/url/#
instead of
/http:\/\/match\/this\/url\//
Note that whatever character you use will then need to be escaped if
used within the regex.
--
Bowie
Re: SPF_HELO_PASS,SPF_NONE
On Jan 5, 2015 at 18:52 +0100, Reindl Harald wrote: =how can SPF_HELO_PASS,SPF_NONE fire both? Just by going off the names... The domain presented in the HELO (RFC5321.HELO) command passed the SPF check_host() test while the domain used in the mail from (RFC5321.MailFrom) command didn't have a SPF record. S1: 220 mx.example.com ESMTP C1: EHLO smtp.example.net S2: 250-mx.example.com Hello...pleased to meet you C2: MAIL FROM:sen...@example.net S2: 250 Sender OK C3: RCPT TO:recipi...@example.com S3: 250 Recipient OK C4: DATA So the SPF_HELO_PASS is testing the SPF record for smtp.example.net (line C1 above), while the SPF_NONE is testing the domain (example.net) used in the MAIL FROM (line C2). Remember that SPF checks both the HELO name presented as well as the domain used in the Mail From command. (Which is why you should have a simple v=spf1 a -all record for the A record of your sending systems as well as not having your sending systems HELO as your top level domain.) -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: regex: chars to escape bsides @
Am 05.01.2015 um 19:14 schrieb Bowie Bailey:
On 1/4/2015 5:42 AM, Reindl Harald wrote:
Am 04.01.2015 um 06:43 schrieb Bob Proulx:
The additional issue was that you were referencing PHP documentation.
Might as well have been referencing Lisp documentation for all of the
relevance it had. That was the point I saw being addressed at that
point. PHP is a similar syntax that came after Perl but it very much
is its own thing and Perl does not derive from it
we are talking about PCRE and the PHP function preg_quote() to escape
a string for *perl* regular expressions not the language syntax and
since the backneds are alreay there i just asked *what* chars
*additional* to that function needs to be escaped *besides* the @ i
found out myself
that is a short and simple question and not refer to the used PHP
function would not have been hepful at all
Ok. Here is an attempt at a simple answer off the top of my head. (Not
guaranteed to be complete)
The following characters may need to be escaped in a Perl regex (as used
in SA) if intended to be used as literal characters:
$%@/[{*+?\
] and } may need to be escaped as well, but I don't think it is required.
You can avoid having to escape the slash (/) by using a different
separator for the regex. This can avoid leaning toothpick syndrome.
thanks, i ended last night in the wrapper-function below while / already
got escaped since this is also needed for postfix header_checks
so finally there was only % missing i got aware on that thread, @ was
already handeled after taking notice and the rest is done properly by
preg_quote()
[harry@srv-rhsoft:/downloads]$ cat test.php
#!/usr/bin/php
?php
$chars = '$ % @ / [ ] { } \ * + ? ! \\';
echo $chars . \n;
echo preg_quote($chars) . \n;
echo sa_quote($chars) . \n;
function sa_quote($input)
{
$input = str_replace(array(\n, \r, \0), '', trim($input));
$input = str_replace(\t, ' ', $input);
$input = preg_quote($input);
$input = str_replace('/', '\/', $input);
$input = str_replace('@', '\@', $input);
$input = str_replace('%', '\%', $input);
return $input;
}
?
[harry@srv-rhsoft:/downloads]$ ./test.php
$ % @ / [ ] { } \ * + ? ! \
\$ % @ / \[ \] \{ \} \\ \* \+ \? \! \\
\$ \% \@ \/ \[ \] \{ \} \\ \* \+ \? \! \\
signature.asc
Description: OpenPGP digital signature
Re: SPF_HELO_PASS,SPF_NONE
Am 05.01.2015 um 19:22 schrieb Derek Diget: On Jan 5, 2015 at 18:52 +0100, Reindl Harald wrote: =how can SPF_HELO_PASS,SPF_NONE fire both? Just by going off the names... The domain presented in the HELO (RFC5321.HELO) command passed the SPF check_host() test while the domain used in the mail from (RFC5321.MailFrom) command didn't have a SPF record. S1: 220 mx.example.com ESMTP C1: EHLO smtp.example.net S2: 250-mx.example.com Hello...pleased to meet you C2: MAIL FROM:sen...@example.net S2: 250 Sender OK C3: RCPT TO:recipi...@example.com S3: 250 Recipient OK C4: DATA So the SPF_HELO_PASS is testing the SPF record for smtp.example.net (line C1 above), while the SPF_NONE is testing the domain (example.net) used in the MAIL FROM (line C2). so far clear, but i am in favor of *not* issue *any* positive score if the sending domain just don't have a SPF record which is the case if SPF_HELO *and* SPF_NONE both hits @domaintechnik.at don't publish SPF regardless over what server it was sent and so i see no valid reason for a positive score of outgoing mails over host5.ssl-gesichert.at[213.145.228.32] Remember that SPF checks both the HELO name presented as well as the domain used in the Mail From command. (Which is why you should have a simple v=spf1 a -all record for the A record of your sending systems as well as not having your sending systems HELO as your top level domain.) nope, define IP or network ranges of the systems allowed to send and you are done, it works properly and saves dns requests or at least additional traffic (faced all sorts of troubles in the past with hostnames in SPF in case of network troubles here and there and never had a single SPF issue after switch all domains to ipv4 notation) thelounge.net. 86400 IN TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 -all rhsoft.net. 86400 IN TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 ip4:85.124.176.243 -all signature.asc Description: OpenPGP digital signature
Re: spamassassin bayes rules
Anybody can help with this? I still cannot find some helpful information, thanks. Dne 10.12.2014 v 14:52 Christian Grunfeld napsal(a): when you run bayes in SQL and does sa-learn --username it will not try to setuid to that user (in a real system user scenario it will fail for non existent users). Instead it uses that username to save and recall data from database. Due to forged addresses your system treat any originating address as yours and then try to interact with the DB. **-u* /username/, *--username*=/username/* If specified this username will override the username taken from the runtime environment. You can use this option to specify users in a virtual user configuration. NOTE: This option will not change to the given /username/, it will only attempt to act on behalf of that user. Because of this you will need to have proper permissions to be able to change files owned by /username/. In the case of SQL this generally is not a problem. A lot of time ago I came with the same problem to Marc Martinec and he implemented some sort of checks of addreses to see if they are local to you or notbut I dont remeber Cheers 2014-12-10 10:22 GMT-03:00 Filip Havlíček filip.havli...@pro-com.cz mailto:filip.havli...@pro-com.cz: Hi, I have configured spamasssin with bayes user rules with this configuration: http://pastebin.com/KWW78DJx I would like to ask you, if everything is correct, because I found in table bayes_vars lot of (thousands) unknown email addresses like: a...@hotmail.com mailto:a...@hotmail.com ablewi...@hotmail.com mailto:ablewi...@hotmail.com abl...@hotmail.com mailto:abl...@hotmail.com My table bayes_token is also 350MB large! Thanks for your help.
Re: user scores not used by spamassassin
On 1/4/2015 10:40 PM, J.J. Day wrote:
Hi Kevin,
Thanks for the link. It's a starting point. As far as the two
functions are concerned, I was just hoping to short cut the process of
finding them.
Actually, I am a pretty good programmer in half a dozen languages -
it's just that I have never used Perl. Since the problem isn't an
overlooked parameter setting, it looks like I will have to add Perl to
the library unless the mimedefang people can provide an existing hook.
Happy to help. However, if you can program, then I think you are
tackling to much at once.
My approach would be:
Stage 1: get SpamAssassin working with MD (look at one of the default
milter examples for Windows)
Stage 2: get SA working with MD with an sa_object
At the top of your filter:
if ($Features{SpamAssassin}) {
#$SALocalTestsOnly = 1; # I do NOT want network tests
$SALocalTestsOnly = 0; # I DO want network tests
#REMOVED PER DFS BUT NOT REALLY SURE WHY ;-)
#spam_assassin_init()-compile_now(1) if defined(spam_assassin_init());
#Switched to $sa_object as returned by SA per DFS
$sa_object = spam_assassin_init() if defined(spam_assassin_init());
}
Stage 3: then add the few extra lines to switch to a different user hard
coded to a specific user
Stage 4: Add logic for the username that that you need with good use of
the md_syslog function for logging
Programming for MD requires a bit of ground work so read the mimedefang
filter example and the mimedefang-filter man page
Also, if you are going to discuss programming in MD on the MD list, you
really need to post the error you get along with things like your
filter. You didn't give us much to go on but as mentioned, this is the
wrong list anyway, just lots of crossover with SA and MD.
Good luck!
Regards,
KAM
Re: regex: chars to escape bsides @
On Mon, 5 Jan 2015, Bowie Bailey wrote: You can avoid having to escape the slash (/) by using a different separator for the regex. This can avoid leaning toothpick syndrome. For example: m#http://match/this/url/# Ouch. # won't work for that (in SA at least) as it comments out the rest of the RE. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Where are my space habitats? Where is my flying car? It's 2010 and all I got from the SF books of my youth is the lousy dystopian government. -- perlhaqr --- 12 days until Benjamin Franklin's 309th Birthday
