Re: 550-IMAP/POP3: understanding returns/bounces error mssg
li...@sbt.net.au: > : host target.tld[69.175.yyy.xxx] > said: 550-Please turn on SMTP Authentication in your mail client, or > login to the 550-IMAP/POP3 server before sending your message. > geko.sbt.net.au 550-[180.235.131.4]:51667 is not permitted to relay > through this server without 550 authentication. (in reply to RCPT TO > command) What is the real server name? What is the real IP address? Wietse
Re: 550-IMAP/POP3: understanding returns/bounces error mssg
On Fri, October 11, 2013 10:31 pm, Wietse Venema wrote: > What is the real server name? > What is the real IP address? Wietse, thanks, from the log entry: corporatechange.com.au 69.175.105.186 BUT, looking at recent log entries, mail seems now delivered, THOUGH, log now show different IP for the server: Oct 11 17:56:45 geko postfix/smtp[1927]: 079F23829BA: to=, relay=corporatechange.com.au[50.87.106.83]:25, delay=4.6, delays=0.05/0.01/1.3/3.3, dsn=2.0.0, status=sent (250 OK id=1VUWeS-0006Kx-6R)
Re: 550-IMAP/POP3: understanding returns/bounces error mssg
li...@sbt.net.au: > On Fri, October 11, 2013 10:31 pm, Wietse Venema wrote: > > > What is the real server name? > > What is the real IP address? > > Wietse, > > thanks, from the log entry: > > corporatechange.com.au > 69.175.105.186 That IP address belongs to Singlehop. > BUT, looking at recent log entries, mail seems now delivered, THOUGH, log > now show different IP for the server: > > Oct 11 17:56:45 geko postfix/smtp[1927]: 079F23829BA: > to=, > relay=corporatechange.com.au[50.87.106.83]:25, delay=4.6, > delays=0.05/0.01/1.3/3.3, dsn=2.0.0, status=sent (250 OK > id=1VUWeS-0006Kx-6R) And that IP address belongs to Unifiedlayer. As required by the SMTP protocol Postfix relies on DNS to deliver mail. If a DNS server provides incorrect information (intermediate DNS resolver or authoritative DNS server) then that is a problem that Postfix cannot solve. Wietse
[Aside] Alternatives to content inspection?
A recent postfix-users thread had comments (about Spamassassin) along the lines of content inspection being evil by design. (Andreas and Stan) In my mind content inspection would include anti-virus checking. Am I wrong? I recognize postscreen as an effective defence. But there are other kinds of attacks. It seems the only thing to attempt to identify spear phishing is content inspection. When someone takes the time and puts out the effort to target an organization, appearing to be from that organization, I know of no other way than to do pattern matching against email content. If I am trying the wrong approach I would like to know. What are the alternative that are successfully used? Especially in the area of Spear Phishing? -- Robert Lopez
Re: [Aside] Alternatives to content inspection?
On Fri, Oct 11, 2013 at 11:49:14AM -0600, Robert Lopez wrote: > A recent postfix-users thread had comments (about Spamassassin) along the > lines of content inspection being evil by design. (Andreas and Stan) Participants in email discussions are always tempted to pontificate. I would not take such categorical prouncements too seriously. Content inspection is for most sites a *necessary* evil. In a more perfect world with no malicious adversaries we'd not need it. In the real world we do, and the benefits substantially exceed the costs. Choose your content inspection tools with care. -- Viktor.
Re: [Aside] Alternatives to content inspection?
Zitat von Robert Lopez : A recent postfix-users thread had comments (about Spamassassin) along the lines of content inspection being evil by design. (Andreas and Stan) In my mind content inspection would include anti-virus checking. Am I wrong? At least my comment was in the context of spam, not malware. Even the human recipients sometimes have trouble to decide by content what is spam, so a automatic detection for such a diffuse target is doomed to fail. Furthermore if you don't use pre-queue filter (most content filter don't), you have no useful option what to do with spam-tagged mail. I recognize postscreen as an effective defence. But there are other kinds of attacks. It seems the only thing to attempt to identify spear phishing is content inspection. When someone takes the time and puts out the effort to target an organization, appearing to be from that organization, I know of no other way than to do pattern matching against email content. If I am trying the wrong approach I would like to know. What are the alternative that are successfully used? Especially in the area of Spear Phishing? Real Spear Phishing is handcrafted special targeted, so you won't detect it with automatic content filters which rely on patterns and already known URLs and the like anyway. If the sender is able to fool the human recipient it is also able to fool the content filter, taken it is not a widspread already known attack which is also caught by RBL/Postscreen/Greylisting etc. Baseline is you might gain some low additional percentage spam caught with a big percentage additional problems. I have seen to many mail silently vanish in some spam-folder to believe that content filters could be desireable. But as always: YMMV Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: [Aside] Alternatives to content inspection?
On Fri, Oct 11, 2013 at 09:28:38PM +0200, lst_ho...@kwsoft.de wrote: > Even the human recipients sometimes have trouble to decide by content > what is spam, so a automatic detection for such a diffuse target is > doomed to fail. This is plainly false. A filter does not have to detect all spam. All it has to do is detect most spam, and rarely generate FPs. There is no "doomed to fail" if the problem is correctly defined. Anyway this is off topic. Can we stop? -- Viktor.
Re: master.cf listed in dbl.spamhaus.org
Daniele Nicolodi skrev den 2013-10-10 11:27: I guess there is not much we can do about it, but I found it funny. # local.cf uridnsbl_skip_domain main.cf master.cf
Re: [Aside] Alternatives to content inspection?
I am more interested in the non-antivirus aspect of this content inspection conversation. So far the open-source ones out there (SpamAssasin, Spamprobe, DSpam) all seem to be *kind of* OK at best but not nearly as effective as needed. I train these tools with thousands upon thousands of messages as well as configure them with different settings all of the time and yet these tools will catch about only 40% of the spam coming in. My guess is that simply spammers have more or less figured out the Bayesian and other mathematical filters and thus they aren't as effective as they could be. On the plus side there is much less false positives than other tools so that's a plus. Regards, Christopher Koeber On Fri, Oct 11, 2013 at 2:02 PM, Viktor Dukhovni wrote: > On Fri, Oct 11, 2013 at 11:49:14AM -0600, Robert Lopez wrote: > > > A recent postfix-users thread had comments (about Spamassassin) along the > > lines of content inspection being evil by design. (Andreas and Stan) > > Participants in email discussions are always tempted to pontificate. > I would not take such categorical prouncements too seriously. > > Content inspection is for most sites a *necessary* evil. In a more > perfect world with no malicious adversaries we'd not need it. In > the real world we do, and the benefits substantially exceed the > costs. Choose your content inspection tools with care. > > -- > Viktor. >
Re: master.cf listed in dbl.spamhaus.org
Stan Hoeppner skrev den 2013-10-10 12:06: I tend to agree. SA has a poor FP track record here. sa 3.4 rc3 is just relaesed today but is the problem that sa uses headers to make uribl check on ? imho email headers should not trick urls testing, but none have fixed it yet
Re: master.cf listed in dbl.spamhaus.org
John Levine skrev den 2013-10-10 21:17: I suspect either it's just a mistake, or stuff that actually used that domain in a URL (as opposed to just a random string in a message)q has been really spammy. I asked. There really is a domain master.cf, and it really is used in URLs in a lot of spam. Solution: don't look up strings in the DBL that aren't host names in URLs. and spamhaus have imho no uribl lists, so where is the problem then ? # local.cf uridnsbl_skip_domain master.cf blacklist_from *@master.cf was the intention from spamhaus, where is the problem ?
Some postfix delivering problems
Hi
I am getting some problems with my postfix installation. I use
postfix+amavis+clamav+spamassassin in a Debian box.
I recently changed from sendmail+canit pro to this configuration.
The last error I get is something like:
Command time limit exceeded: "procmail -a "$EXTENSION""
But there are many messages not delivered with error messages like:
Considered UNSOLICITED BULK EMAIL, apparently from you
Most of these messages seem to be DNS related, cause I get extra info like:
First upstream SMTP client IP address: [proxy ip]
proxy.raconsultores.com.mx
According to a 'Received:' trace, the message originated at:
[proxy ip],
AUDITORIA proxy.raconsultores.com.mx [proxy ip] <--- I put the text
in place of the ip
Senders are in a LAN behind a proxy and mail server is in another network
(we have 2 dedicated links).
In the last sample AUDITORIA is the name of a PC in the lan. There are some
other similar messages coming from other PCs.
The last messages related to UBE include something like:
Missing required header field: "Date"
Here is my postconf -n output:
--
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = mail.raconsultores.com.mx, localhost, raconsultores.com.mx,
fiscum.com.mx, haltunspa.com.mx, racorporativo.com.mx, joinbusiness.com.mx,
jbcapital.com.mx, zcmodelos.com.mx, gruporama.com.mx
mydomain = raconsultores.com.mx
myhostname = mail.raconsultores.com.mx
mynetworks = proxyip/32,mailservernetwork.0/28 <--- Of course, the file
includes the proper ip's.
myorigin = $mydomain
readme_directory = no
recipient_delimiter = +
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP (Debian/GNU)
smtpd_recipient_restrictions = permit_inet_interfaces permit_mynetworks
permit_sasl_authenticated check_relay_domains reject_unauth_destination
check_client_access hash:/etc/postfix/rbl_override
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
--
I put spf records in the zone files, like:
raconsultores.com.mx. IN TXT "v=spf1 mx ~all"
(Indeed, after that I get less errors about UBE)
What could be wrong?
thanks in advice.
Armando
--
View this message in context:
http://postfix.1071664.n5.nabble.com/Some-postfix-delivering-problems-tp62117.html
Sent from the Postfix Users mailing list archive at Nabble.com.
