[IMGate] Signed up for the spf stuff
Just curious on if any of you are signing up for this service? http://spf.pobox.com/
[IMGate] Re: Signed up for the spf stuff
Just curious on if any of you are signing up for this service? http://spf.pobox.com/ ---start of one man's opinion... quick! hit delete if you are easily offended :) No. Not until the big guys start using it. I don't mean when they add the records to their own domains, but instead, when they actually reject mail based on the absence of the spf records of others. Until then, it think it just makes some folks feel good to be in the spf club, but there really is no tangible benefit yet. ---end of opinion
[IMGate] Re: Problem with main.cf syntax
I just encountered an issue with the main.cf file as provided by Len for the basic Imgate configuration and hope someone can clarify the situation for me. The issue came up when I needed to whitelist an email recipient address for a few of our users to the configuration and came across what looks to me like an error in the syntax. When I looked the the file main.cf I saw 2 lines that on their own as shown below: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unverified_recipient, hash:/etc/postfix/to_recipients_bw.map, reject_unknown_sender_domain, permit_mynetworks, reject_unauth_destination, hash:/etc/postfix/to_recipients_bw.map, Shouldn't the hash:/etc/postfix/to_recipients_bw.map be on the same line as one of the restrictions as the maptype:mapname? no, because we are in the smtpd_recipient_restrictions already Also there are some reject_ restrictions here I don't see listed in the Postfix book I have. Is the /etc/postfix/to_recipients_bw.map the correct place to add email addresses for our users who don't want email blocked? yes, see man 5 access The users in question receive email from Korea for potential students and since I set up IMGate here they are being contacted by people telling them that email from these potential Korean students is being rejected. look in the log file to see why exactly. if the rejects are for header or body checks due to kr character set, you remove the kr from filter. This is found by inspection. :) smtpd process to_recipients_bw whitelisting won't have any effect on rejects done by the cleanup process. I have asked for the specific bounce messages but to date non have been supplied making it more difficult to track down the problem. egrep the maillog file Len
[IMGate] Re: Problem with main.cf syntax
From: Richard Edge [EMAIL PROTECTED] I just encountered an issue with the main.cf file as provided by Len for the basic Imgate configuration and hope someone can clarify the situation for SNIP Is the /etc/postfix/to_recipients_bw.map the correct place to add email addresses for our users who don't want email blocked? The users in question receive email from Korea for potential students and since I set up IMGate here they are being contacted by people telling them that email from these potential Korean students is being rejected. Korean mail is probably being blocked by either header checks or body checks- since Len is very agressive in blocking asian sourced spam. IIRC body checks has several checks for foreign character sets. Header/Body checks apply to all mail and I don't think you can selectivly bypass them. I have asked for the specific bounce messages but to date non have been supplied making it more difficult to track down the problem. I also don't want to open it up to allow spam to the rest of our users. The purpose here is for two deparments who need to receive email from Korea, English as a Second Language Institute and our Korean Worldview Studies program. Any suggestions would be helpful. Your missing bounces were probably returned to the Korean students who cannot send a copy your user- I doubt they can send you a copy of the bounce! What Postfix book are you referencing? If the book was based on 1.x, there are many things added to 2.0 and even 2.2! Gerry
[IMGate] Re: Signed up for the spf stuff
Also, there's nothing to sign up for. You can use SPF whether you register with spf.pobox.com or not. It is just DNS records.=20 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob McGregor Sent: Wednesday, March 30, 2005 4:30 PM To: IMGate List Subject: [IMGate] Signed up for the spf stuff Just curious on if any of you are signing up for this service? http://spf.pobox.com/
[IMGate] Re: Signed up for the spf stuff
Just curious on if any of you are signing up for this service? http://spf.pobox.com/ I follow the SPF list, here's msg of frustration from recently: I want an RfC for v=spf1 a.s.a.p. All these permanent modifications like adding zone-cut, removing zone-cut, use PRA instead of MAIL FROM, don't use PRA, MAYbe test HELO, ignore HELO, SHOULD test HELO, limit the processing time to at least 20 seconds, at most 20 seconds, at least 10 indirections, at most 10 indirectionss, exactly 10 mechanisms, 10 queries, etc. ...all this infuriates me. V=spf1 is supposed to be stable for more than a year now. I'm not interested in new features, as long as we don't have this one really stable RfC. Even if it is only experimental. In your case I felt that you insisted on going through a wall (anything with DNS is a wall from my POV), where I could see the SIQ-door, but couldn't explain the wall-part. Chris Haynes has now done it: It's not a theoretical problem with DNS, but only a practical problem with the deployment of new uses of DNS queries for new RRs like the future SPF RR. Back to square one: Adding new features to DNS is no option but a bad case of FUSSP - when all DNS libraries, servers, firewalls, and what else are updated. Yes, then we could do wonderful things. We could even forget SPF and implement CSV. But in practice that's not possible. SPF has reasons to abuse TXT at the moment, and this moment will last for decades plus the time wasted to get a RfC with the new SPF RR (without your modified query), It was a design decision to have a 1:1 correspondence between the old TXT RR solution and the new SPF RR. Maybe add an optional additional info section with the IP to these queries for v=spf6 or spf/6.0 later. But please stay away from v=spf1 as is before we have some kind of official RfC for v=spf1. It's already hell to get at least so far. The very last v=spf1 needs now are some new features. Let alone new features in its DNS layer. I appreciate your frustration. It sure seems like the entire technical community is floundering over what should be a simple standard. I don't mean the SPF standard, but a standard that all methods can live within. This would not include any controversial items like redirected queries, but just those few items needed for inter-operability of all methods. My worry is that we might get agreement within the SPF community, barely squeeze it through IETF, then face adamant opposition from SenderID, DomainKeys, and any other group that doesn't like the letters SPF in an authentication header. My suggestion is that we take one little step backwards and try for a standard that everyone can agree on (or at least make clear that their objections are frivolous). With a few items standardized, SPF and any other method can do whatever they want within the standard, and the much bigger community that is not involved in the competition between authentication methods (spam filter companies, ISPs, spam blocking services, etc.) - that much larger community can move forward, knowing exactly what an authentication header will look like. As for the opposition from the DNS community, I may be wrong because I haven't reviewed the earlier controversies, but I'll bet we can get them to help if we address their fundamental concerns, and enlist their help in coming up with a solution. We need them to think as proud fathers, not jealous guardians. Surely they would like to have their invention be a key player in the solution to a serious international problem. If not, there are alternatives. Here is what I see as the fundamental requirements for a standard authentication query: 1) The authentication query must be quick and independent of any particular method. The alternative is to have the sender declare the authentication method in the envelope, but let's put that option aside for the moment. 2) The response must be quick and allow rejection of most forgeries with no additional queries. I'm tempted to suggest how this might be done, but first let's see if anyone has objections to these requirements, or anything else we should add at this level. == Len from here: I get the general impression that SPF people are self-importantly debating angels on a pinhead. Meanhwile, only a tiny fraction of .com's 35 million domains have published SPF records, not even thinking about the many millions of domains under other TLDs. SPF sounded really simple and effective, but apparently not the case. there's spf1, spf2, spf classic, ad nauseam. Based on the number of legit servers, at this very late date in the spam war, that don't have PTR records, don't even have valid HELO hostnames, I'm very skeptical they will ever have SPF records. How to use SPF by your MS? @sender.domain has no SPF records? can't reject @sender.domain has SPF records, and msg is from SPF-defined IP, trust and accept? no, spammer domain have SPF
[IMGate] Re: Problem with main.cf syntax
-Original Message- no, because we are in the smtpd_recipient_restrictions already Okay, got it. yes, see man 5 access Hadn't checked there. I was using the book instead. look in the log file to see why exactly. if the rejects are for header or body checks due to kr character set, you remove the kr from filter. This is found by inspection. :) Tried that unfortunately they could not enven provide a date or time and with the tousands of other responsibilities I have I want the onus to be on the user complaing to at least provide me with enough criteria to narrow the search. I though I would check the list for other tips. smtpd process to_recipients_bw whitelisting won't have any effect on rejects done by the cleanup process. Understood I have asked for the specific bounce messages but to date non have been supplied making it more difficult to track down the problem. egrep the maillog file Like I said I would do this but without more details I am not going to search a months worth of logs if the user isn't going to meet me half-way. I use grep and the logs regularly but I always ask for enough details to begin a search or I would spend all my time doing so. Email administration is not my only responsibility. Thanks for the your help it has given me a couple of other areas to check. Richard Edge Senior Systems Administrator | Technology Services Trinity Western University | t: 604.513.2089 f: 604.513.2038 | e: [EMAIL PROTECTED] | www.twu.ca/technology -- Binary/unsupported file stripped by Ecartis -- -- Type: application/x-pkcs7-signature -- File: smime.p7s
[IMGate] Re: Signed up for the spf stuff
So, is SPF a whitelist feature? a blacklist feature? Since most of us have solved 98+% of our SPAM probles, SPF will at very best be tiny increment of help, and we are a long way from very best SPF implementation. Len I see SPF records adding a low weight in the entire anti-spam system, but I see SPF as a whitelist feature. IMO SPF is dead as they high jacked a DNS record, spammers are adding SPF records faster than anyone, and not many admins can setup the mail server correctly as RFC's provide already. IMO the overall problem is the IT profession, IT went from professionals to anyone that could pass the M$ tests and could get cheap highspeed access for cheap. They aren't many true professionals in the IT field anymore ... again IMO ... it's really sad. ---off the soap box--- Christopher Checca Packard Transport, Inc. IT Department 24021 South Municipal Dr PO Box 380 Channahon, IL. 60410 815 467 9260 815 467 6939 Fax [EMAIL PROTECTED] www.packardtransport.com
[IMGate] Re: Signed up for the spf stuff
Personally I'd like to see Marking Mail Transfer Agents in Reverse DNS with TXT RRs ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt move forward and get adopted. Sounds good to me, but so did SPF in the beginning. :) mtamark has, for me, the same problem as with SPF: When so many legit server have no PTR (we can't reject alone for no PTR) and bad helo (they can't set up their SMTP box), what chance is there for mtamark? However, the ground will move when/if aol/earthlink/yahoo/msn/hotmail ALL insist on PTR and valid helo. Then we can set our policies in sync with those de facto industry policies, with no need to hassle with recalcitrants. You can't send to aol/earthlink/yahoo/msn/hotmail with you noPTR/badHELO, and you WON'T send to my MX, either. From that point, then we can move try mtamark. The problem with mtamark is that so many legit orgs do not have authority over their reverse zone, making mtamark records dependent on the DNS admin for the reverse zone. Len
[IMGate] Re: Signed up for the spf stuff
Quoting Len Conrad [EMAIL PROTECTED]: Personally I'd like to see Marking Mail Transfer Agents in Reverse DNS with TXT RRs ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt move forward and get adopted. Perhaps I misunderstood this RFC but it seems trivial for spammers to mark their ip's with a 1 or spam friendly providers to do the same. I agree it's effective against hijacked workstations, but then so is greylisting. Andrew P. Kaplan www.cshore.com This message was sent using IMP, the Internet Messaging Program.
