Re: Max Size Not Working Correctly?

W dniu 2009-04-23 17:14, Rick Duval pisze: You are truncating all the long logfile records. Wietse Sorry I didn't even realize that was happening. I dl'd the file and copied and pasted instead of grabbing from putty which I guess was only grabbing the screen. Apr 22 13:52:55 v

Re: Question regarding SPF

W dniu 2009-04-17 08:50, Kammen van, Marco, Springer SBM NL pisze: Hi All, We recently took over a company that used SPF. Because our e-mail infra is way more complicated than theirs and we have tons of external parties who send mails using our domains, we decided long ago not to use SPF.

Re: Now OT. Terminating thread (was Re: A better backscatter killer?)

W dniu 2009-04-15 04:21, Rod Whitworth pisze: --Original Message Text--- *From:* Pawe+‚ Le+›niak *Date:* Tue, 14 Apr 2009 14:50:57 +0200 8>< snip- I don't like top-posting but.. Due to your message formatting it is not possible for someone to easily see who said what in your reply. S

Re: Sender with invalid domain

W dniu 2009-04-14 23:47, mouss pisze: Paweł Leśniak a écrit : W dniu 2009-04-14 23:00, mouss pisze: [snip] and spammers seem to forge valid addresses, so the check looks useless to me. How do they forge a client DNS A records consistent with PTR records? I meant

Re: A better backscatter killer?

W dniu 2009-04-14 23:11, mouss pisze: Ralf Hildebrandt a écrit : * MacShane, Tracy: Then you won't receive some genuine messages, both bounce and non-bounce. Try the ips.backscatterer.org RBL; it works well for us. http://www.mailinglistarchive.com/postfix-users@postfix.org/msg5740

Re: Sender with invalid domain

W dniu 2009-04-14 23:00, mouss pisze: Paweł Leśniak a écrit : W dniu 2009-04-13 22:46, mouss pisze: does reject_unknown_sender_domain really reject that many spam (that is not rejected by zen among other things)? According to RFC1912: (...) 2.1 Inconsistent, Missing, or Bad

Re: A better backscatter killer?

W dniu 2009-04-14 13:54, Rod Whitworth pisze: Remember I did say that I was applying this to "null sender to non-existing recipients" (who were purported to be the original senders). We have about 60 spamtrap addresses. Most invented by spammers. I'd imagine somewhat better usage of spam-tra

Re: A better backscatter killer?

W dniu 2009-04-14 11:56, Rod Whitworth pisze: Oh dear, that's all really too much trouble. I have OpenBSD's spamd running in front of my MTA. A script checks all greylisted entries for invalid recipients with<> sender and tarpits them. If mail goes to invalid recipient it can be *rejected*.

Re: A better backscatter killer?

W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze: They are retarded. mail.charite.de is listed in it. You're definitely not right. Testresult for 141.42.4.200: This IP IS CURRENTLY NOT LISTED in our Database. B U T, it was listed in the past ! History: 2008/05/13 08:49listed 2008/06/10

Re: Sender with invalid domain

W dniu 2009-04-13 22:46, mouss pisze: does reject_unknown_sender_domain really reject that many spam (that is not rejected by zen among other things)? According to RFC1912: (...) 2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host *should* have a name. The consequences of

Re: Backscatter

W dniu 2009-04-05 04:27, Sahil Tandon pisze: On Sat, 04 Apr 2009, LuKreme wrote: On 4-Apr-2009, at 16:02, Noel Jones wrote: Best in smtpd_data_restrictions so you don't reject sourceforge and others sender verification probes. Is there anything I need to be concerned about h

Re: Backscatter

W dniu 2009-04-04 20:09, LuKreme pisze: I've seen an increase in backscatter emails recently. Perfectly valid headers (AFAICT) Return-Path: <> X-Original-To: kr...@kreme.com Delivered-To: kr...@covisp.net Received: from mail9.webair.com (mail9.webair.net [74.206.236.69]) by mail.covisp.net

Re: Sender vs recipient restrictions.

W dniu 2009-03-18 14:23, Costin Guşă pisze: On Wed, Mar 18, 2009 at 3:11 PM, wrote: I've been reading today about; reject_unknown_sender_domain and I'm wondering if it is only allowed under 'smtpd_sender_restrictions' whereas I've had it under 'smtpd_recipient_restrictions'. Is this corre

Re: Spam attacks

W dniu 2009-03-05 06:30, Mihira Fernando pisze: Have you ever tried sending an e-greeting to someone via 123greeting.com or some other similar site ? You're definitely right - I didn't use that one before. Look what I get in logs: Mar 5 09:41:50 lola postfix/smtpd[20278]: warning: 72.233.20

Re: Blocking a domain and user

W dniu 2009-03-04 21:32, Jim McIver pisze: I have Postfix 2.1 on Freebsd 4.10 and am having trouble blocking email from a domain. Here is a snipet of the postqueue -p: DF6A927D 3512 Tue Mar 3 18:42:35 MAILER-DAEMON (connect to mx1.mail.yahoo.co.jp[124.83.183.240]: server dropped conne

Re: Spam attacks

On 3/4/2009, PaweB Le[niak (warl...@lesniakowie.com) wrote: Looking at first email in thread carefully you'd see that Dave has (or had) problem with spam sent from j...@foo.com to j...@foo.com. And that's the case where authentication will do the job perfectly - IMHO way better then zen.

Re: postconf -n suggestion

W dniu 2009-03-04 20:53, Charles Marcus pisze: Irrelevant. There is nothing wrong with simplifying things... Simplifying does not mean changing behavior. As Wietse said, postconf -n shows only setting from main.cf. So adding values from outside main.cf is not simplifying at all. By your ar

Re: postconf -n suggestion

I was just talking about something that would make it easier when someone was asking for help on the list... I don't think the above will quite accomplish that... In many cases (I'm not gonna do statistics) new users do not post their questions correctly - often we can see 2nd message in th

Re: Spam attacks

On Wed March 4 2009 08:48:18 Paweł Leśniak wrote: But then we come to definition of spam. It's in simple words unwanted message. Too simple, and not correct. The true definition of spam is UBE: unsolicited bulk email. Most spammers put out messages that a tiny percenta

Re: Messages Are Refused

I am noticing that for some reason every time a specific user on my domain attempts to email a particular domain, the messages are always queued up. They don't ever appear to send for some reason and I checked the logs which don't really give any specific reason why he can't send email to this do

Re: Spam attacks

I can state with authority that mail with sender==recipient is not universally 100% spam, and such a policy would likely have a much higher false positive rate than zen. You can argue it's a misconfiguration of the sender, but a mail admin's job is to receive legit mail. but you're welcome to

Re: FW: Spam attacks

Hi all Just to clarify some points They are running an IMAP server with SASL login for remote users IMAP let's you get mail from your account. So it's really not related to your problem. You'd have to use SMTP authentication so when one wants to send mail from u...@example.com to anotheru..

Re: Spam attacks

W dniu 2009-03-03 18:41, Noel Jones pisze: Some legit "reminder" type services, some meeting notifications, and other legit mail might arrive with you as the sender. Maybe not best practices, but it's legit mail and such a policy will reject it. Why would someone want to fake sender address? Is

Re: Spam attacks

W dniu 2009-03-03 23:34, MacShane, Tracy pisze: We have a very clear policy that users are only permitted to relay mail from our networks. If they are sending from home, they use webmail. We've had one or two instances where external organisations have used some kind of auto-reply mechanism whic

Re: Spam attacks

W dniu 2009-03-03 17:46, Noel Jones pisze: Some people reject their own domain from outside, unauthenticated clients, but this will certainly reject some amount of legit mail. Could you write a little bit how is it possible to reject legit mail by rejecting unauthenticated clients when all use

Re: Spam attacks

W dniu 2009-03-03 08:25, Dave Johnson pisze: Hi all Is there anyway of stopping the from "j...@foo.com" to "j...@foo.com" spam attacks? Hi Without knowing your config it's hard to say what are you already doing. Are you using SASL authentication? If not, have a loo

Re: whitelisting trusted addresses

Hello, Did you try dnswl.org ? Pawel

Re: user getting spoofed

Noel Jones pisze: jeff donovan wrote: Greetings I have a user whos name is being spoofed by the spammers of the world. and her mailbox is getting flooded by legitimate Mailer Delivery notices. Is there anything i can do for her besides change her account name ? I was thinking about a tempora

Re: rbl clients.

Victor Duchovni pisze: On Thu, Feb 12, 2009 at 02:02:03PM -0500, Linux Addict wrote: Please see below my smtpd_recipient_restrictions. On my rbl client list I have multiple entries, but not sure how many of them actually maintained. Is there one single place where I can find such a list. Any

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

mouss pisze: João Miguel Neves a écrit : OK, I'll take that into consideration if I re-enable SAV. if you re-enable SAV, do as much checks as you can. the minimum is zen.spamhaus.org. but you can also use spamcop. it would also be good to do it after greylisting, but this means your

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

mouss pisze: no reason to overreact. I am not seeing SAV abuse (but I am seeing backscatter and spam). And I do under some circumstances. If I have SPF record, then I'm helping the other side to check if mail with sender from my domain is permitted or not. This means that sender already had

Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

João Miguel Neves pisze: Charles Marcus escreveu: Here's a link informing why indiscriminate use of SAV is bad, and what it should be used for: http://www.backscatterer.org/?target=sendercallouts OK, I've finished reading and analyzing that text. My conclusion is that there's no reason not to

Re: Sender-Recipient forged mail

MacShane, Tracy pisze: -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of itsramesh_s Sent: Friday, 6 February 2009 4:25 PM To: postfix-users@postfix.org Subject: Sender-Recipient forged mail Hi, I have configured postfix

Re: User getting back scattered

body check if /^[> ]*Received:/ /^[> ]*Received: +from +(beth\.k12\.pa\.us) / reject forged client name in Received: header: $1 /^[> ]*Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(beth\.k12\.pa\.us)\)/ reject forged client name in Received: header: $2 /^[> ]*Received:.* +by +(beth\.k

Re: Backscatter with forged return-path

mouss pisze: Paweł Leśniak a écrit : mouss pisze: reject_unknown_helo_hostname would indeed be too aggressive. but you could use restriction classes and only call it if the sender is null (<>). or you could run aggressive checks if the client has a "generic" reverse

Re: Backscatter with forged return-path

mouss pisze: reject_unknown_helo_hostname would indeed be too aggressive. but you could use restriction classes and only call it if the sender is null (<>). or you could run aggressive checks if the client has a "generic" reverse dns. or in this particular case, simply reject *.rev.dynxnet.com

Re: Backscatter with forged return-path

Jim Wright pisze: On Jan 26, 2009, at 4:05 PM, Paweł Leśniak wrote: I may be wrong, but I think I should not block sender on helo basis? Most of what will be blocked are zombie systems that send no legitimate mail, a very small number of legitimate mails 'may' be blocked. It&#x

Re: Backscatter with forged return-path

mouss pisze: if all outbound mail goes via your server, you can use "poorman BATV". for example: use smtp_generic to rewrite j...@example.com to say joe+bou...@example.com, where '+' is your extension delimiter. then you can reject mail from the null sender if it is not sent to a /\+bou...@examp

Re: Backscatter with forged return-path

Jim Wright pisze: Jan 26 13:05:42 mail postfix/policy-spf[2500]: : Policy action=PREPEND Received-SPF: none (server.hipwah.com: No applicable sender policy available) receiver=mail.example.com; identity=helo; helo=SERVER.hipwah.com; client-ip=202.134.118.114 reject_unknown_hostname SERVER.hip

Re: Backscatter with forged return-path

mouss pisze: This doesn't mean all your users mail has such message-id's: - the message-id is added by the MUA. so if the MUA is named joe.my.computer, the message-id will use this instead of example.com. - if your users post from other servers (their ISP, hotel, ...), the message-id may be that

Re: Backscatter with forged return-path

Chris Babcock pisze: On Mon, 26 Jan 2009 08:52:00 -0600 Jim Wright wrote: On Jan 26, 2009, at 7:41 AM, Paweł Leśniak wrote: One of our users is getting lots of returned mails because his email address is used as return-path by spammer(s). I would guess that your system

Re: Backscatter with forged return-path

Jim Wright pisze: On Jan 26, 2009, at 7:41 AM, Paweł Leśniak wrote: One of our users is getting lots of returned mails because his email address is used as return-path by spammer(s). I would guess that your system accepting mail from unknown servers? Start blocking those, and you'll

Re: Preventing domain mails from outside

Specifically I added check_sender_access hash:/etc/postfix/copycats to smtpd_recipient_restrictions= after the mynetworks and SASL authenticated permits, added an /etc/postfix/copycats file containing thisisreallymydomain.com REJECT This seems to be effective at stopping some of the spa