Re: RBL Spam question
On 11/05/10 00:11, Stan Hoeppner wrote: Michael Orlitzky put forth on 11/4/2010 8:06 PM: On 11/04/2010 12:39 AM, Stan Hoeppner wrote: Ned Slider put forth on 11/3/2010 6:33 PM: My other thought was to simply comment (or document) ranges known to contain FPs and then the user can make a judgement call whether they want to comment out that particular regex based on their circumstances. Not a very elegant solution. I'm starting to wonder, considering your thoughts on FPs, if this might be better implemented, for OPs concerned with potential FPs, via a policy daemon, or integrated into SA somehow and used for scoring instead of outright blocking. I don't have the programmatic skill to implement such a thing. http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC Any idea where I can get a look that the regexes they use in this rule? I think this is the latest: http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf
Re: RBL Spam question
Michael Orlitzky put forth on 11/5/2010 1:39 AM: On 11/05/10 00:11, Stan Hoeppner wrote: Michael Orlitzky put forth on 11/4/2010 8:06 PM: On 11/04/2010 12:39 AM, Stan Hoeppner wrote: Ned Slider put forth on 11/3/2010 6:33 PM: My other thought was to simply comment (or document) ranges known to contain FPs and then the user can make a judgement call whether they want to comment out that particular regex based on their circumstances. Not a very elegant solution. I'm starting to wonder, considering your thoughts on FPs, if this might be better implemented, for OPs concerned with potential FPs, via a policy daemon, or integrated into SA somehow and used for scoring instead of outright blocking. I don't have the programmatic skill to implement such a thing. http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC Any idea where I can get a look that the regexes they use in this rule? I think this is the latest: http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf Did you happen to notice the absolutely tiny number of expressions in the SA file, as compared to the ~1600 in the file whose use I promote here? Maybe I should get in contact with someone in the project. If only half were deemed usable by them it would be a huge improvement over what they have. -- Stan
Re: RBL Spam question
On 11/05/10 03:01, Stan Hoeppner wrote: http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf Did you happen to notice the absolutely tiny number of expressions in the SA file, as compared to the ~1600 in the file whose use I promote here? Maybe I should get in contact with someone in the project. If only half were deemed usable by them it would be a huge improvement over what they have. Some guy named Stan Hoeppner suggested that the OP might want to use the list for scoring in SpamAssassin. My point was that if he wants to do that, he could just add them to the existing 20_dynrdns.cf file =)
Re: RBL Spam question
On Fri, Nov 05, 2010 at 02:01:19AM -0500, Stan Hoeppner wrote: Michael Orlitzky put forth on 11/5/2010 1:39 AM: On 11/05/10 00:11, Stan Hoeppner wrote: Michael Orlitzky put forth on 11/4/2010 8:06 PM: On 11/04/2010 12:39 AM, Stan Hoeppner wrote: Ned Slider put forth on 11/3/2010 6:33 PM: My other thought was to simply comment (or document) ranges known to contain FPs and then the user can make a judgement call whether they want to comment out that particular regex based on their circumstances. Not a very elegant solution. I'm starting to wonder, considering your thoughts on FPs, if this might be better implemented, for OPs concerned with potential FPs, via a policy daemon, or integrated into SA somehow and used for scoring instead of outright blocking. I don't have the programmatic skill to implement such a thing. http://wiki.apache.org/spamassassin/Rules/RDNS_DYNAMIC Any idea where I can get a look that the regexes they use in this rule? I think this is the latest: http://svn.apache.org/repos/asf/spamassassin/rules/branches/3.2/20_dynrdns.cf Did you happen to notice the absolutely tiny number of expressions in the SA file, as compared to the ~1600 in the file whose use I promote here? Maybe I should get in contact with someone in the project. If only half were deemed usable by them it would be a huge improvement over what they have. Did you happen to notice the absolutely generic expressions in the SA file, unlike your file which mostly lists specific domains? Not that I don't agree the whole SA file should be revamped, but you are again jumping the gun.
Re: serious bug with check_client_access
On 2010-11-04 23:36:04 -0300, Reinaldo de Carvalho wrote: On Thu, Nov 4, 2010 at 11:13 PM, Vincent Lefevre vinc...@vinc17.net wrote: Yes, it will generate *some* lookups, but it doesn't say exactly *which* lookups. That was precisely my question. - client hostname (reverse dns hostname) - client IP address. OK, and mous said in that order (but maybe that's just the current implementation, and the user shouldn't rely on the order for the future). if smtpd_access_maps in parent_domain_matches_subdomains. - compare client hostname without the first part at left by dot - compare client hostname without the first and the second part at left by dot (and recursively at the TDL) but not with a regular expression table. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: serious bug with check_client_access
On 2010-11-05 06:21:20 +0100, mouss wrote: in short, for each map, you have multiple parameters: - the map type - the search context (check_client_access, check_sender_acces, ... transport, virtual_alias_maps, ... etc) - the list of search keys [...] Thanks a lot for this very detailed answer. This was exactly the kind of description I was looking for. I have only one comment: [hash/cdb/...] - if parent_domain_matches_subdomains contains smtpd_access: here, the search list is S = ( lab1.lab2.lab3.example.com, lab2.lab3.example.com, lab3.example.com ..., com, 1.2.3.4, 1.2.3, 1.2, 1 ) so postfix will search for each element of this set and stops as soon as a match is found. Testing the tld alone seems to be excluded by the access(5) man page, which only documents domain.tld, i.e. the pattern must contain at least one dot. Is it an error in the man page (which could say domain instead, like in Section Email address extension) or is it intentional? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: Relaying denied during 2 hours, driving me crazy
Zitat von mouss mo...@ml.netoyen.net: Le 05/11/2010 05:54, Pablo Chamorro a écrit : Today we had a 'relaying denied' issue between 15:08-17:02 p.m. Here it is the output of pflogsumm: Per-Hour Traffic Summary time received delivered deferredbounced rejected -0100 0 0 0 0 0 0100-0200 0 0 0 0 0 0200-0300 0 0 0 0 0 0300-0400 0 0 0 0 0 0400-0500 897958 51 9 10 0500-0600 835873 62 1 19 0600-0700 938 1019 53 1 16 0700-08001257 1455 73 0 10 0800-09001833 2413 38 1 26 0900-10001926 2574 70 8 25 1000-11001859 3029 72 9 29 1100-12001998 2529 31 3 13 1200-13001553 1845 52 7 27 1300-14001349 1593 47 5 20 1400-15001758 2166 62 4 23 1500-16001941 2473 31143 33 1600-17002072 5745 17283 31 1700-18002008 2821 18 2 15 1800-19001468 1769 10 0 32 1900-20001213 2391 45 71 22 2000-21001013 1119 32 0 8 2100-2200 988 1082 32 1 8 2200-23001100 3458 30 3 19 2300-2400 523550 9 2 2 The problem wasn't specific for one domain. It happened the same for Yahoo, Hotmail, GMail and others. But, according to the above table, it seems, just some of them were bounced, weren't they? I wonder what happened. Could somebody please give me an answer about what could have happened? Below a log of a sent and bounced message, as far as I understand: -- sent message, start -- Nov 4 16:02:44 correo postfix/pickup[20590]: 9198E2D6A7A: uid=101 from=amcard...@ingeominas.gov.co Nov 4 16:02:44 correo postfix/cleanup[14980]: 9198E2D6A7A: message-id=20101104210235.m95...@correo.ingeominas.gov.co Nov 4 16:02:44 correo postfix/qmgr[14629]: 9198E2D6A7A: from=amcard...@ingeominas.gov.co, size=2113, nrcpt=1 (queue active) Nov 4 16:02:44 correo postfix/smtp[18151]: 9198E2D6A7A: to=unbitl...@gmail.com, relay=127.0.0.1[127.0.0.1]:10024, delay=0.23, delays=0.07/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20341-15, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as AC18C2D6A1F) Nov 4 16:02:44 correo postfix/qmgr[14629]: 9198E2D6A7A: removed -- end -- -- bounced message, start -- Nov 4 16:02:44 correo postfix/smtpd[7447]: AC18C2D6A1F: client=localhost.localdomain[127.0.0.1] Nov 4 16:02:44 correo postfix/cleanup[17693]: AC18C2D6A1F: message-id=20101104210235.m95...@correo.xxx.gov.co Nov 4 16:02:44 correo postfix/qmgr[14629]: AC18C2D6A1F: from=amcard...@xxx.gov.co, size=2590, nrcpt=1 (queue active) Nov 4 16:02:44 correo amavis[20341]: (20341-15) Passed CLEAN, [127.0.0.1]amcard...@xxx.gov.co - xx...@gmail.com, Message-ID:20101104210235.m95...@correo.xxx.gov.co, mail_id: 4-lL-jKSP5zp, Hits: -, size: 2113, queued_as: AC18C2D6A1F, 154 ms Nov 4 16:02:44 correo postfix/smtp[18151]: 9198E2D6A7A: to=xx...@gmail.com, relay=127.0.0.1[127.0.0.1]:10024, delay=0.23, delays=0.07/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20341-15, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as AC18C2D6A1F) Nov 4 16:02:45 correo postfix/smtp[20466]: AC18C2D6A1F: to=xx...@gmail.com, relay=gmail-smtp-in.l.google.com[74.125.45.27]:25, delay=0.91, delays=0.07/0.01/0.71/0.12, dsn=5.0.0, status=bounced (host gmail-smtp-in.l.google.com[74.125.45.27] said: 550 Relaying denied. (in reply to RCPT TO command)) hmmm. here: $ host 74.125.45.27 27.45.125.74.in-addr.arpa domain name pointer yx-in-f27.1e100.net. $ host gmail-smtp-in.l.google.com gmail-smtp-in.l.google.com has address 209.85.227.27 74.125.45.27 is a google IP, but I don't see it listed as the IP of one of the MX's. At our side of the planet: ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com. 2462IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 2462IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 2462IN MX 40
Re: Well, everyone else using dnswl.org say bye bye to opensource usage.
On 11/4/2010 5:54 AM, Jerrale G wrote: hellopostmas...@shetoncomputers.com, You are receiving this message from dnswl.org because we try to identify and notify current users of our service about upcoming changes. If you are not the right contact for issues dealing with spamfilters, whitelisting and DNS, we would appreciate if you could either forward this message or let us know about better contacts. Dnswl.org is changing it's operating model (seehttp://www.dnswl.org/news/ for more details), and as part of this change, we are shutting down the rsync service which until now was available at rsync1.dnswl.org, and which we believe you are currently using. We made a best guess that you could be the contact for the following IP/Domain we extracted from our rsync logfiles: IP address 173.50.101.14 Domain sheltoncomputers.com In order to use the rsync service under the new operating model, all users will need to be registered and have a valid, paid subscription. Registration is available at https://subscription.dnswl.org Please note that we will start shutting down the old rsync service over the next days and weeks. Your access may be affected at any time as well. If you have questions, please refer to our websitehttp://dnswl.org/ or contact us by e-mail atoff...@dnswl.org. Kind regards, -- Matthias Leisi, dnswl.org project leader you know, they could have made a premium service or addition to offset overhead and generate revenue while having the white and blacklists as a free service. This means that spamassassin's accuracy, and opensource, will reduce as well. I guess Im going to have to consider dspam even more now. Jerrale G I was merely saying that changes were going to have to be made to postfix and/or spamassassin, with which one depending on your configuration. Why do people get so ANGRY when trying to participate in online functions where text or original authoring is required? God Bless, Jerrale G. SC Senior Admin
Re: Relaying denied during 2 hours, driving me crazy
On 5/11/10 4:31 PM, mouss wrote: hmmm. here: $ host 74.125.45.27 27.45.125.74.in-addr.arpa domain name pointer yx-in-f27.1e100.net. $ host gmail-smtp-in.l.google.com gmail-smtp-in.l.google.com has address 209.85.227.27 74.125.45.27 is a google IP, but I don't see it listed as the IP of one of the MX's. Whereas I have: bash-3.2$ host 74.125.45.27 27.45.125.74.in-addr.arpa domain name pointer yx-in-f27.1e100.net. bash-3.2$ host gmail-smtp-in.l.google.com gmail-smtp-in.l.google.com has address 74.125.155.27 bash-3.2$ This is because Google use geolocation IPs. For specific hosts you will obtain the IP that appears to be closest to your network. Regards, Ben signature.asc Description: OpenPGP digital signature
Re: Relaying denied during 2 hours, driving me crazy
Zitat von Ben McGinnes b...@adversary.org: On 5/11/10 4:31 PM, mouss wrote: hmmm. here: $ host 74.125.45.27 27.45.125.74.in-addr.arpa domain name pointer yx-in-f27.1e100.net. $ host gmail-smtp-in.l.google.com gmail-smtp-in.l.google.com has address 209.85.227.27 74.125.45.27 is a google IP, but I don't see it listed as the IP of one of the MX's. Whereas I have: bash-3.2$ host 74.125.45.27 27.45.125.74.in-addr.arpa domain name pointer yx-in-f27.1e100.net. bash-3.2$ host gmail-smtp-in.l.google.com gmail-smtp-in.l.google.com has address 74.125.155.27 bash-3.2$ This is because Google use geolocation IPs. For specific hosts you will obtain the IP that appears to be closest to your network. It looks like gmail-smtp-in.l.google.com is in fact different dependant from where you are looking at it. It is the MX with highest priority, but as said even from my side of the planet the IP listed at the OPs message is a valid MX for gmail.com so it should not reply relay denied. On the other hand i have seen MXs replying with relay denied when they in fact mean user does not exist. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: cidr table performance
Jeroen Geilman wrote:
for (entry = list; entry; entry = entry-next) {
Each map is a linked list of CIDR patterns, so consolidate as much as
possible - 10 single IPs will cause noticable delays when the last
entry matches!
Funny coincidence: just yesterday I added a Patricia (radix) trie search
to SpamAssassin, which also needs to check if an IP address matches
a list of included/excluded CIDR ranges of IPv6 or IPv4 addresses.
For large lists the speedup can be substantial. Now a lookup takes
about 0.2 ms (in Perl), regardless of the size of a table - which is
a nice property of a radix trie (commonly used with IP routing tables).
Bug 6508: Speeding up lookups on {trusted,internal,msa}_networks
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6508
Patricia trie on Wikipedia:
http://en.wikipedia.org/wiki/Patricia_trie
Net::Patricia perl module on CPAN:
http://search.cpan.org/dist/Net-Patricia/
Mark
Accepting / Rejecting mails
Hello, I want to configure postfix so that mails to u...@localhost and u...@host.subdomain.domain are only accepted if the mail origins from an IP address in $mynetworks, but that mails to u...@subdomain.domain are always accepted. How can I do that? Regards Christoph
trivial-rewrite and postgres setup
hi, i'm using postfix 2.5.5 with a postgres backend setup. everything works fine (as far as i can see) but looking at my logfiles i'm wondering why the domain part of sender addresses is being looked up in my virtual_mailbox_domains table. i'm seeing lines like these in my logfiles: postfix/trivial-rewrite[12345]: warning: table pgsql:/etc/postfix/virtual_mailbox_domains: empty lookup result for: senderdomain.com -- ignored is this related to address verification or is it an indication of misconfiguration? as is said everything works fine but i think these lookups might cause performance problems when the server gets busy. i'm willing to post configuration details, i just wanted to ask the basic question first. thx for advice matthias
Re: RBL Spam question
Henrik K put forth on 11/5/2010 2:49 AM: Did you happen to notice the absolutely generic expressions in the SA file, unlike your file which mostly lists specific domains? The bulk of them are specific to a given ISP. I saw a half dozen that are generic. Not that I don't agree the whole SA file should be revamped, but you are again jumping the gun. I don't see how contacting them and suggesting they might benefit from additional regexes is premature in any way. If you think this is premature, does that mean you believe I should contact them later instead of sooner? Should I be waiting for some event to occur that signals the timing is correct at that point, instead of being premature? -- Stan
Re: trivial-rewrite and postgres setup
Matthias Leopold: hi, i'm using postfix 2.5.5 with a postgres backend setup. everything works fine (as far as i can see) but looking at my logfiles i'm wondering why the domain part of sender addresses is being looked up in my virtual_mailbox_domains table. i'm seeing lines like these in my logfiles: postfix/trivial-rewrite[12345]: warning: table pgsql:/etc/postfix/virtual_mailbox_domains: empty lookup result for: senderdomain.com -- ignored Lookup tables (SQL or otherwise) should return NOT FOUND instead of returning zero-length result. Wietse
Re: serious bug with check_client_access
Vincent Lefevre put forth on 11/5/2010 4:03 AM: Testing the tld alone seems to be excluded by the access(5) man page, which only documents domain.tld, i.e. the pattern must contain at least one dot. Is it an error in the man page (which could say domain instead, like in Section Email address extension) or is it intentional? If you want to block rDNS TLDs this PCRE works with check_client_access: /^.*?(info|kr|jp|sg|qa)$/i 550 We do not accept mail from .$1 domains You could also use this for check_sender_access, check_helo_access, etc--it should work with any check that passes a string with .tld in it. -- Stan
Re: RBL Spam question
On Fri, Nov 05, 2010 at 09:11:39AM -0500, Stan Hoeppner wrote: Henrik K put forth on 11/5/2010 2:49 AM: Did you happen to notice the absolutely generic expressions in the SA file, unlike your file which mostly lists specific domains? The bulk of them are specific to a given ISP. I saw a half dozen that are generic. And the generic ones probably match the bulk of your rules. Your 1600 rules comparison didn't make any sense. Of course you are free to file a SA bug/feature or even become a committer yourself so you can mass check the rules. But it's beyond this list.
Re: Accepting / Rejecting mails
On 11/5/2010 8:32 AM, Christoph Pleger wrote: Hello, I want to configure postfix so that mails to u...@localhost and u...@host.subdomain.domain are only accepted if the mail origins from an IP address in $mynetworks, but that mails to u...@subdomain.domain are always accepted. How can I do that? Regards Christoph Use a check_recipient_access map somewhere after permit_mynetworks. Basic example: # main.cf smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination check_recipient_access hash:/etc/postfix/restricted_receipt # restricted_receipt localhost.my.domain REJECT some message localhost REJECT local use only sub.my.domain REJECT for local use only Be sure to postmap restricted_receipt after editing it. Be sure to run postfix reload after editing main.cf. -- Noel Jones
DNS Whitelisting
Noel Jones wrote in late August 2010:
B) a permit based system, a mirror of reject_rbl_client.
This would have a user interface similar to the existing
reject_rbl_client with expected usage similar to access(5)
based whitelists.
Seems to me that checks using sender-supplied info such as
{helo, sender domain, recipient domain} are unsafe -- give
whitelist control to unverified information -- and probably
shouldn't be implemented.
To prevent open-relay accidents, this would need to return
permit_auth_destination rather than a blanket permit. Maybe
the result action will need to be configurable? Nah.
The user interface would be familiar to anyone using rbl
checks. Sample documentation under the appropriate
smtpd_mumble_restrictions section:
- permit_dnswl_client dnswl_domain=d.d.d.d
Accept the request when the reversed client IP network
address is listed with an A record of d.d.d.d under
dnswl_domain. If no =d.d.d.d is given, accept the request
with any A record under dnswl_domain. For safety, only
authorized destinations are accepted, see permit_auth_destination.
- permit_rhswl_client rhswl_domain=d.d.d.d
Accept the request when the client hostname is listed with
an A record of d.d.d.d under rhswl_domain. If no =d.d.d.d is
given, accept the request with any A record under
rhswl_domain. For safety, only authorized destinations are
accepted, see permit_auth_destination.
Seems like this one would be very easy to use, and fairly easy
to implement.
This is now implemented with minor changes. Mainly, the discussion
about permit_auth_destination had to be replaced, since that is
not applicable in smtpd_{client,helo,sender}_restrictions context.
I also added a DEFER_IF_REJECT result in case of DNS failure.
The current manpage text reads:
reject_rbl_client rbl_domain=d.d.d.d
...
permit_dnswl_client dnswl_domain=d.d.d.d
Accept the request when the reversed client network address is
listed with the A record d.d.d.d under dnswl_domain. If no
=d.d.d.d is specified, accept the request when the reversed
client network address is listed with any A record under
dnswl_domain.
For safety, permit_dnswl_client is silently ignored when it
would override reject_unauth_destination.The result is
DEFER_IF_REJECT when whitelist lookup fails. This feature is
available in Postfix 2.8 and later.
...
reject_rhsbl_client rbl_domain=d.d.d.d
...
permit_rhswl_client rhswl_domain=d.d.d.d
Accept the request when the client hostname is listed with the A
record d.d.d.d under rhswl_domain. If no =d.d.d.d is speci-
fied, accept the request when the client hostname is listed with
any A record under rhswl_domain.
For safety, permit_rhswl_client is silently ignored when it
would override reject_unauth_destination.The result is
DEFER_IF_REJECT when whitelist lookup fails. This feature is
available in Postfix 2.8 and later.
The safety check literally triggers when permit_dns/rhswl_client
is invoked inside smtpd_recipient_restrictions with a recipient
that would be blocked by reject_unauth_destination.
The above primitives are easily generalized to the unverified reverse
client, helo and sender, but it would seem unwise.
Wietse
Re: DNS Whitelisting
On Fri, Nov 05, 2010 at 11:03:34AM -0400, Wietse Venema wrote: The current manpage text reads: reject_rbl_client rbl_domain=d.d.d.d ... permit_dnswl_client dnswl_domain=d.d.d.d Accept the request when the reversed client network address is listed with the A record d.d.d.d under dnswl_domain. If no =d.d.d.d is specified, accept the request when the reversed client network address is listed with any A record under dnswl_domain. For safety, permit_dnswl_client is silently ignored when it would override reject_unauth_destination.The result is DEFER_IF_REJECT when whitelist lookup fails. This feature is available in Postfix 2.8 and later. ... reject_rhsbl_client rbl_domain=d.d.d.d ... permit_rhswl_client rhswl_domain=d.d.d.d Accept the request when the client hostname is listed with the A record d.d.d.d under rhswl_domain. If no =d.d.d.d is speci- fied, accept the request when the client hostname is listed with any A record under rhswl_domain. For safety, permit_rhswl_client is silently ignored when it would override reject_unauth_destination.The result is DEFER_IF_REJECT when whitelist lookup fails. This feature is available in Postfix 2.8 and later. Looks good. Should we mention that these should only be used to reduce FPs from blacklists that follow, and that are expected to not list legitimate clients. Thus any temporary DNS lookup error would likely result an an additional lookup that incurrs a low risk or rejection, but does *imply* rejection. DNS-based positive access rules are fragile with respect to the semantics of temporary lookup failures, and must not be used to permit some while denying all. There will at some point be interest in DNSWL support for verified DKIM d= domains. For now that's out of scope (milters, pre-queue filters, ...) I've recently starting using the OpenDKIM library, ... it is fairly easy to support. If there is ever interest in directly supporting DKIM in the Postfix SMTP server, I'm game to talk design. Due to the DNS lookup latency inherent in incoming DKIM checks, doing DKIM in post-queue content-filters is somewhat unattractive, as typically one wants low-latency, modest concurrency in a post-queue filter. -- Viktor.
Re: DNS Whitelisting
On 11/5/2010 10:03 AM, Wietse Venema wrote: This is now implemented with minor changes. Excellent! Looking forward to a test drive. -- Noel Jones
Re: DNS Whitelisting
Victor Duchovni: On Fri, Nov 05, 2010 at 11:03:34AM -0400, Wietse Venema wrote: The current manpage text reads: reject_rbl_client rbl_domain=d.d.d.d ... permit_dnswl_client dnswl_domain=d.d.d.d Accept the request when the reversed client network address is listed with the A record d.d.d.d under dnswl_domain. If no =d.d.d.d is specified, accept the request when the reversed client network address is listed with any A record under dnswl_domain. For safety, permit_dnswl_client is silently ignored when it would override reject_unauth_destination.The result is DEFER_IF_REJECT when whitelist lookup fails. This feature is available in Postfix 2.8 and later. ... reject_rhsbl_client rbl_domain=d.d.d.d ... permit_rhswl_client rhswl_domain=d.d.d.d Accept the request when the client hostname is listed with the A record d.d.d.d under rhswl_domain. If no =d.d.d.d is speci- fied, accept the request when the client hostname is listed with any A record under rhswl_domain. For safety, permit_rhswl_client is silently ignored when it would override reject_unauth_destination.The result is DEFER_IF_REJECT when whitelist lookup fails. This feature is available in Postfix 2.8 and later. Looks good. Should we mention that these should only be used to reduce FPs from blacklists that follow, and that are expected to not list legitimate clients. Thus any temporary DNS lookup error would likely result an an additional lookup that incurrs a low risk or rejection, but does *imply* rejection. DNS-based positive access rules are fragile with respect to the semantics of temporary lookup failures, and must not be used to permit some while denying all. I agree that whitelisting on client names is fragile (whether one uses a static whitelist map or DNS lookups), because the client name lookup will sometimes fail due to some temporary error. The DEFER_IF_REJECT result cited above handles only whitelist lookup problems; it is easy enough to hard-code the same in permit_*wl_client for temporary client name lookup problems, but I see no easy way to automatically fall back to DEFER_IF_REJECT for all name-based mechanisms. There will at some point be interest in DNSWL support for verified DKIM d= domains. For now that's out of scope (milters, pre-queue filters, ...) I've recently starting using the OpenDKIM library, ... it is fairly easy to support. If there is ever interest in directly supporting DKIM in the Postfix SMTP server, I'm game to talk design. I'm not yet in a hurry to build those 3-4 letter alphabet soup protocols into Postfix. Due to the DNS lookup latency inherent in incoming DKIM checks, doing DKIM in post-queue content-filters is somewhat unattractive, as typically one wants low-latency, modest concurrency in a post-queue filter. This is where before-queue filtersand Milters are in a better position. I expect that there will be pressure to move away from after-queue filters, despite the limitations of the before-queue approach. Wietse
Re: DNS Whitelisting
Should we mention that these should only be used to reduce FPs from blacklists that follow, and that are expected to not list legitimate clients. ... Depends on the whitelist. I'm working on Spamhaus' new whitelist where our goal is to list only mail sources clean enough that you can skip the rest of the filtering. (So far so good, but it's still pretty small.) You're welcome to use it. The IP address version is at swl.spamhaus.org. For people who like DKIM, there's also domain version at dwl.spamhaus.org. It lists domains, with the ONLY use that we support being DKIM d= signing domains on mail with valid signatures. See RFC 5518. The terms of use are the same as the rest of the Spamhaus lists, moderate number of queries are fine, larger than that and you have to buy a feed. If you already have a Spamhaus feed, the SWL and DWL should now be included in it. The plan for the SWL and DWL is that we will eventually charge for listings, but for now it's free, in limited beta. See http://www.spamhauswhitelist.com/en/, and drop me a line if you'd like an invitation. R's, John
Re: DNS Whitelisting
On Fri, Nov 05, 2010 at 12:27:06PM -0400, Wietse Venema wrote: Should we mention that these should only be used to reduce FPs from blacklists that follow, and that are expected to not list legitimate clients. Thus any temporary DNS lookup error would likely result an an additional lookup that incurrs a low risk or rejection, but does *imply* ^^^ Missed a: not rejection. DNS-based positive access rules are fragile with respect to the semantics of temporary lookup failures, and must not be used to permit some while denying all. I agree that whitelisting on client names is fragile (whether one uses a static whitelist map or DNS lookups), because the client name lookup will sometimes fail due to some temporary error. The DEFER_IF_REJECT result cited above handles only whitelist lookup problems; it is easy enough to hard-code the same in permit_*wl_client for temporary client name lookup problems, but I see no easy way to automatically fall back to DEFER_IF_REJECT for all name-based mechanisms. This strategy upgrades all temporary name lookup problems to DEFER_IF_REJECT when a permit_rhswl_client is encountered before a reject action. This has the unfortunate effect of making all invalid traffic from systems with broken DNS retry. I think this is not viable, that the better option is to have a fragile whitelist, which sometimes fails to whitelist, but that's OK, because one expects the blacklists to not list the good guys. We are changing the FP rate, not promising zero FPs. In any case, this needs a bit of care in documentation and perhaps design. -- Viktor.
Re: DNS Whitelisting
On Fri, Nov 05, 2010 at 04:51:14PM -, John Levine wrote: Should we mention that these should only be used to reduce FPs from blacklists that follow, and that are expected to not list legitimate clients. ... Depends on the whitelist. I'm working on Spamhaus' new whitelist where our goal is to list only mail sources clean enough that you can skip the rest of the filtering. (So far so good, but it's still pretty small.) Yes, and same said sources should not be blacklisted by anything that follows. If Postfix can't determine the client's reverse domain (tempfail) and therefore cannot even ask SpamHaus whether the (verified) client (PTR) domain is on the whitelist, one can either tempfail all mail from said client (bad, lots of retransmitted garbage) or fail to white-list (not so bad, worst case the blacklists will FP a small fraction of legit clients, choose your blacklists with care). You're welcome to use it. The IP address version is at swl.spamhaus.org. The IP version does not encounter the issue, as we don't expect systemic tempfail issues with swl lookups, but we expect systemic problems obtaining verified (IP - PTR - matching-IP) names for many clients. For people who like DKIM, there's also domain version at dwl.spamhaus.org. It lists domains, with the ONLY use that we support being DKIM d= signing domains on mail with valid signatures. See RFC 5518. Hence my comment about possible appetite for DKIM in smtpd/cleanup. The terms of use are the same as the rest of the Spamhaus lists, moderate number of queries are fine, larger than that and you have to buy a feed. If you already have a Spamhaus feed, the SWL and DWL should now be included in it. The plan for the SWL and DWL is that we will eventually charge for listings, but for now it's free, in limited beta. See http://www.spamhauswhitelist.com/en/, and drop me a line if you'd like an invitation. I have an invitation, my problem is that I don't yet have separate infrastructure for just non-marketing email. In a large enough organization, someone, somewhere will unilaterally engage in some marketing under the radar, so we need to think about separating the known good, rather than trying to preclude the unknown bad. -- Viktor.
Open relay question
Dear, I'm in Internet and testing if my mail server is an Open Relay. So I execute: telnet mail.mycompany.com 25 After that I do: mail from: us...@mycompany.com OK rcpt to: us...@mycompany.com OK data This is a test !!! . QUEUED The mail from user1 to user2 (both from my company) was sent OK !!! Is this behavior normal or is it an open relay ??? Can I sent a message from one local user to another local user, being that I come from Internet and not from LAN ??? Thanks a lot A.F.
Re: cidr table performance
On 11/05/2010 02:16 PM, Mark Martinec wrote:
Jeroen Geilman wrote:
for (entry = list; entry; entry = entry-next) {
Each map is a linked list of CIDR patterns, so consolidate as much as
possible - 10 single IPs will cause noticable delays when the last
entry matches!
Funny coincidence: just yesterday I added a Patricia (radix) trie search
to SpamAssassin, which also needs to check if an IP address matches
a list of included/excluded CIDR ranges of IPv6 or IPv4 addresses.
For large lists the speedup can be substantial. Now a lookup takes
about 0.2 ms (in Perl), regardless of the size of a table - which is
a nice property of a radix trie (commonly used with IP routing tables).
Bug 6508: Speeding up lookups on {trusted,internal,msa}_networks
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6508
Patricia trie on Wikipedia:
http://en.wikipedia.org/wiki/Patricia_trie
That would revolutionize IP lookups on routers, firewalls etc.
Unless they already use this, of course - I know mainly Cisco equipment :)
It's a pity I can't code to save my life, this sounds incredibly cool.
Net::Patricia perl module on CPAN:
http://search.cpan.org/dist/Net-Patricia/
Mark
--
J.
Re: Open relay question
On 11/5/2010 2:28 PM, Alejandro Facultad wrote: Dear, I'm in Internet and testing if my mail server is an Open Relay. So I execute: telnet mail.mycompany.com 25 After that I do: mail from: us...@mycompany.com OK rcpt to: us...@mycompany.com OK data This is a test !!! . QUEUED The mail from user1 to user2 (both from my company) was sent OK !!! Is this behavior normal or is it an open relay ??? Can I sent a message from one local user to another local user, being that I come from Internet and not from LAN ??? Thanks a lot A.F. Yes, that's normal. Open relay means the RCPT can be an unrelated domain eg. @hotmail.com.
Re: Open relay question
Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? I now SPF is ideal for avoid this behavior, but I think the first example is an open relay feature. Thanks a lot. De: Noel Jones njo...@megan.vbhcs.org Para: postfix-users@postfix.org Enviado: viernes, 5 de noviembre, 2010 16:32:01 Asunto: Re: Open relay question On 11/5/2010 2:28 PM, Alejandro Facultad wrote: Dear, I'm in Internet and testing if my mail server is an Open Relay. So I execute: telnet mail.mycompany.com 25 After that I do: mail from: us...@mycompany.com OK rcpt to: us...@mycompany.com OK data This is a test !!! . QUEUED The mail from user1 to user2 (both from my company) was sent OK !!! Is this behavior normal or is it an open relay ??? Can I sent a message from one local user to another local user, being that I come from Internet and not from LAN ??? Thanks a lot A.F. Yes, that's normal. Open relay means the RCPT can be an unrelated domain eg. @hotmail.com.
Re: Open relay question
On 11/05/2010 03:41 PM, Alejandro Facultad wrote: Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? I now SPF is ideal for avoid this behavior, but I think the first example is an open relay feature. What about smtp auth? Thanks a lot. *De:* Noel Jones njo...@megan.vbhcs.org *Para:* postfix-users@postfix.org *Enviado:* viernes, 5 de noviembre, 2010 16:32:01 *Asunto:* Re: Open relay question On 11/5/2010 2:28 PM, Alejandro Facultad wrote: Dear, I'm in Internet and testing if my mail server is an Open Relay. So I execute: telnet mail.mycompany.com 25 After that I do: mail from: us...@mycompany.com mailto:us...@mycompany.com OK rcpt to: us...@mycompany.com mailto:us...@mycompany.com OK data This is a test !!! . QUEUED The mail from user1 to user2 (both from my company) was sent OK !!! Is this behavior normal or is it an open relay ??? Can I sent a message from one local user to another local user, being that I come from Internet and not from LAN ??? Thanks a lot A.F. Yes, that's normal. Open relay means the RCPT can be an unrelated domain eg. @hotmail.com.
Re: Open relay question
On Fri, 2010-11-05 at 12:41 -0700, Alejandro Facultad wrote: Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? I now SPF is ideal for avoid this behavior, but I think the first example is an open relay feature. Thanks a lot. __ De: Noel Jones njo...@megan.vbhcs.org Para: postfix-users@postfix.org Enviado: viernes, 5 de noviembre, 2010 16:32:01 Asunto: Re: Open relay question On 11/5/2010 2:28 PM, Alejandro Facultad wrote: Dear, I'm in Internet and testing if my mail server is an Open Relay. So I execute: telnet mail.mycompany.com 25 After that I do: mail from: us...@mycompany.com OK rcpt to: us...@mycompany.com OK data This is a test !!! . QUEUED Hello, If you can connect into a mail server externally (e.g mycompany.com) and send mail through that server without having to provide any means of authentication to another domain entirely (e.g myothercompany.com) then that is an open relay. AFAICT your example used the same domain. If the mail server was configured to accept mail for 'mycompany.com' then it's doing its job in your example. HTH. Regards, Pete. signature.asc Description: This is a digitally signed message part
Re: Open relay question
On 11/05/2010 12:41 PM, Alejandro Facultad wrote: Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? I now SPF is ideal for avoid this behavior, but I think the first example is an open relay feature. Thanks a lot. Hi Alejandro, The example you described is not relaying. Relaying is when the MTA you connected to needs to send the message to another server. Being an open relay means the MTA will receive messages for anyone on the Internet to anyone on the Internet. Hope that clears things up. -will
Re: Open relay question
On 11/5/2010 2:41 PM, Alejandro Facultad wrote: Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? I now SPF is ideal for avoid this behavior, but I think the first example is an open relay feature. Open relay is about the recipient domain, not the sender domain. If you don't want to allow your own domain as unauthenticated sender, you can control that with a check_sender_access map. Examples are in the mail list archives.
Re: Open relay question
On Fri, Nov 05, 2010 at 12:41:06PM -0700, Alejandro Facultad wrote: Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? Don't confuse the envelope sender (which most recipients neither see nor understand) with the From: header which most recipients do see and don't understand. The From: header is easily (and often legitimately) forged. For example, the Postfix-users list sends your own posts to you, from the Internet. The From: header still bears your address. Sure, the envelope sender is not, but the risk you pose applies to the From: header not the envelope. Applying policy restrictions to the From: header, is fraught with complexity and peril. I don't want to get into the politics of SIDF, DKIM, ... the bottom line is that people largely have unrealistic expectations of what email authentication technologies can do for them. -- Viktor.
Re: Open relay question
Le 05/11/2010 20:41, Alejandro Facultad a écrit : Thanks but, is it right if coming from Internet I enter to your mail server and after that I send a message from your mail account to your project manager's mail account telling he's an asshole ??? that's the same as if someone sends you a letter claiming tobe your father and saying the same. it's a lie, not an open relay. an open relay is when someone causes you to annoy someone else. said otherwise: I don't care if joe tells your boss he is an asshole, whomever joe might be. but I wouldn't be happy if _joe_ makes _you_ send _me_ a message (whatever the message is). I now SPF is ideal for avoid this behavior, but I think the first example is an open relay feature. Please don't talk about spf again on this list. spf devots are not welcome here.
Re: Open relay question
Le 05/11/2010 22:26, Alfonso Alejandro Reyes Jimenez a écrit : But that would be spoofing not relay right? Relay is when you let other users send emails to any other domain claiming be someone in your organization. no there's no claim. open relay is when someone uses your server to send mail to people outside of your organisation. it doesn't matter who they claim to be. they can tell the truth. the thing is: it is unauthorized relay. a long time ago, open relay was a natural thing (collaboration). unfortunately, spammers/abusers have killed this collaboration. Spoofing is when you pretend to be someone you are not, right now I cant remember how to prevent this kind of attacks but you may search google (that’s how I fixed it). the first question to ask yourself is: why would you care? in most cases, the recipient can take care of that.
DNS Whitelisting support, uploaded
This is now implemented with minor changes. [...] I have uploaded postfix-2.8-20101105-nonprod for testing (nonprod because this is SMTP server code, and I mostly rely on postscreen's DNS whitelisting feature). ftp://ftp.porcupine.org/mirrors/postfix-release/index.html and mirror sites. Once the code stops changing I can make back-port patches available for older Postfix versions, but I won't include whitelist support with stable releases. Wietse
Re: Do NOT try rDNS Whitelisting
My apologies for shouting, but this wrong idea just won't go away: If Postfix can't determine the client's reverse domain (tempfail) and therefore cannot even ask SpamHaus whether the (verified) client (PTR) domain is on the whitelist, NO! NO, NO, NO! Do NOT look up rDNS in the DWL. If you do, you will get random results, since we have no idea what rDNS our clients use. The Spamhaus DWL is only for DKIM signature domains. If you want to whitelist by sending host, look up the IP address. Once again, do NOT attempt to whitelist on rDNS. We now return you to your previous discussion. R's, John PS: In a large enough organization, someone, somewhere will unilaterally engage in some marketing under the radar, so we need to think about separating the known good, rather than trying to preclude the unknown bad. Quite right. It may be easier to hand out DKIM signing keys to people who know what they're doing, and keep everything else unsigned.
Re: too many recipients does not log
On 11/5/2010 5:59 PM, Richard Stockton wrote: Thanks to those that responded. On Thu, Nov 04, 2010 Victor Duchovni wrote: Is there a way to tell postfix to log a more informational message when smtpd_recipient_limit is exceeded? If it just logged the same message it is sending to the client (452 4.5.3 Error: too many recipients) that would be helpful. Given ESMTP pipelining, this is not a good idea. The client will deliver the accepted recipients, and make a second connection (or more) connection to send the rest. Hi Victor, I don't quite understand what the problem would be with this. It's just writing an additional bit of text to the maillog, preferably at the same time, in the same line, it writes sender non-delivery notification to You're misinterpreting the logs somewhere. Postfix does not and cannot send non-delivery notifications for mail it doesn't receive. The sender non-delivery is not related to the other issue of too many recipients. Also, our customer is unable to determine which, if any, of his emails were actually sent. He just sees the non-delivery notification email Ah, now we learn that you're referring to a client submission rather than general incoming email. All the desktop mail clients I know of will abort the whole transaction if there is an error -- no mail is sent. Is the client using some sort of (garbage) MTA rather than a normal desktop MUA? Did they maybe attempt multiple submissions with a partial recipient list? -- Noel Jones
Re: DNS Whitelisting support, uploaded
On 11/5/2010 6:24 PM, Wietse Venema wrote: This is now implemented with minor changes. [...] I have uploaded postfix-2.8-20101105-nonprod for testing (nonprod because this is SMTP server code, and I mostly rely on postscreen's DNS whitelisting feature). ftp://ftp.porcupine.org/mirrors/postfix-release/index.html and mirror sites. Once the code stops changing I can make back-port patches available for older Postfix versions, but I won't include whitelist support with stable releases. Wietse Seems to work as advertised. This is what I'm using this at the end of smtpd_recipient_restrictions to exempt clients from greylisting. (The warn_if_reject is instrumentation to log when there's a hit during testing.) smtpd_recipient_restrictions = ... usual stuff ... warn_if_reject reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.1 warn_if_reject reject_rbl_client list.dnswl.org warn_if_reject reject_rbl_client swl.spamhaus.org permit_dnswl_client swl.spamhaus.org permit_dnswl_client hostkarma.junkemailfilter.com=127.0.0.1 permit_dnswl_client list.dnswl.org check_policy_service unix:private/greylist -- Noel Jones
