Re: greylisting generates error email?

[Erwan David]

On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme  said:
.
> 
> 
> 
> zen blocks these categories:
> 
> SBL Direct UBE sources, spam operations & spam services
> CSS Direct snowshoe spam sources detected via automation
> CBL (3rd party exploits such as proxies, trojans, etc.)
> PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
> 
> SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL 
> are IPs that the IP owner has classified as not allowed to send mail directly.
> 
> Blocking all of those is perfectly safe.

Perfectly safe is the categorizing process is itself perfect.
ANd since nothing is perfect, you'll always have false positive.

Re: postfix content_filter source address

[Stan Hoeppner]

On 8/20/2013 1:04 AM, Jimmy Stewpot wrote:
> Hello,
> 
> I have recently done a deployment of Postfix 2.10. It seems that the 
> behaviour of postfix has changed slightly in the way that it handles the 
> content_filter variables in the configuration file. We are using 
> content_filter to pass through the emails to Sophos PureMessage for UNIX like 
> so.
> 
> content_filter = smtp:[127.0.0.1]:2500

Is this the verbatim line you used on the RHEL5 box?

> On our old server (Redhat 5) when the content_filter line was in place the 
> spam service would "just work" in that it would see the source and correctly 
> process the emails as an external email.. However with the same version of 
> Pure Message on a new version of Postfix we see that the system is seeing 
> "localhost" as the from relay which means it goes through the localhost 
> whitelist in the spam policy...

"seeing 'localhost' as the from relay"

What was seen previously where you now see "localhost"?

> Am I missing something in the new version of postfix or is that expected 
> behaviour?

This is a fresh Postfix install not an upgrade, correct?  New
main/master.cf?  Parameters copy/pasted?  I'm guessing you simply missed
something when creating the new main/master.cf.  It would be nice to see
your 'postconf -n' output, and any service definitions that exist for
the Sophos program.

-- 
Stan

Re: greylisting generates error email?

[Grant]

>> 
>>
>> zen blocks these categories:
>>
>> SBL Direct UBE sources, spam operations & spam services
>> CSS Direct snowshoe spam sources detected via automation
>> CBL (3rd party exploits such as proxies, trojans, etc.)
>> PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
>>
>> SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. 
>> PBL are IPs that the IP owner has classified as not allowed to send mail 
>> directly.
>>
>> Blocking all of those is perfectly safe.
>
> Perfectly safe is the categorizing process is itself perfect.
> ANd since nothing is perfect, you'll always have false positive.

Has anyone had a confirmed false positive with zen.spamhaus.org ?

- Grant

Re: greylisting generates error email?

[Jose Borges Ferreira]

On Aug 20, 2013 8:03 AM, "Erwan David"  wrote:
>
> On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme  said:
> .
> >
> > 
> >
> > zen blocks these categories:
> >
> > SBL Direct UBE sources, spam operations & spam services
> > CSS Direct snowshoe spam sources detected via automation
> > CBL (3rd party exploits such as proxies, trojans, etc.)
> > PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
> >
> > SBL and CSS are confirmed spammers. CBL are confirmed exploited
machines. PBL are IPs that the IP owner has classified as not allowed to
send mail directly.
> >
> > Blocking all of those is perfectly safe.
>
> Perfectly safe is the categorizing process is itself perfect.
> ANd since nothing is perfect, you'll always have false positive.

+1

Re: greylisting generates error email?

[Stan Hoeppner]

On 8/20/2013 3:06 AM, Grant wrote:

> Has anyone had a confirmed false positive with zen.spamhaus.org ?

http://lmgtfy.com/?q=spamhaus+false+positive

-- 
Stan

TLS errors with GMX/web.de

[Sebastian Wiesinger]

Hello,

GMX and web.de started an initiative for secure E-Mail made in
Germany... they turned TLS on.

But in addition to that bold move the did something else that causes
the following errors when they try to send mail to my postfix:

postfix/smtpd[28706]: connect from mout.web.de[212.227.15.14]
postfix/smtpd[28706]: SSL_accept error from mout.web.de[212.227.15.14]: 0
postfix/smtpd[28706]: warning: TLS library problem: 28706:error:14094438:SSL 
routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1256:SSL alert 
number 80:
postfix/smtpd[28706]: lost connection after STARTTLS from 
mout.web.de[212.227.15.14]
postfix/smtpd[28706]: disconnect from mout.web.de[212.227.15.14]

Postfix 2.9.6 running on Debian 7.1.

This error ONLY occurs with their servers. My question is if anyone
has an idea what could cause this error. My first guess is that they
check certificates for validity and I only have an CACert certificate.
Also I would like to know if anyone else sees this on their postfix?

Currently I've disabled STARTTLS for their mailservers but of course I
would like to use TLS if possible. Would increasing the tls log level
reveal additional helpful information?

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

Re: TLS errors with GMX/web.de

[Heiko Wundram]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 20.08.2013 11:48, schrieb Sebastian Wiesinger:
> This error ONLY occurs with their servers. My question is if
> anyone has an idea what could cause this error. My first guess is
> that they check certificates for validity and I only have an CACert
> certificate. Also I would like to know if anyone else sees this on
> their postfix?

Still delivers fine for me (and my mail-server) running Postfix 2.10.1:

Received: from mout.web.de (mout.web.de [212.227.15.3])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by mail.modelnine.org (Postfix) with ESMTPS id 8854E3640A
for ; Tue, 20 Aug 2013 08:35:39 +0200 (CEST)

- -- 
- --- Heiko.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSEz9zAAoJEDMqpHf921/S1/gIAJolkXgx6z8yVWorTK2xG/F5
CbPJLXBgZhtLQg4zkoXPQGhImXGVK8SesH6fW6E8Pb/+PXROPOtmZ5azFjoBwQVX
6ihljFw8dCQxGW12CTSIs4AvYwv2peaGxWMkIufnSg57xl9b/grdbcujoekCZ70l
FHFT4ZDlZ3X8V52VrvTolUrA0zA3vmzthuNxEhPY00EeSy5qn7usVhFPOhAcSf5T
kwsGnCOo+Fsq8Eejqw4abCGSizO3hWO0tsmqUDo77t8Hp0Pih/yr2jggiwC0F3Xo
T+HHGKCQC1ZSZ+4mLRU7tGk4aDEoaEZhMV955Tr6TYT6K7+29QoBXK+2+4Ru4eg=
=stXd
-END PGP SIGNATURE-

Re: TLS errors with GMX/web.de

[Sebastian Wiesinger]

* Heiko Wundram  [2013-08-20 12:09]:
> Still delivers fine for me (and my mail-server) running Postfix 2.10.1:
> 
> Received: from mout.web.de (mout.web.de [212.227.15.3])
>   (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
>   (No client certificate requested)
>   by mail.modelnine.org (Postfix) with ESMTPS id 8854E3640A
>   for ; Tue, 20 Aug 2013 08:35:39 +0200 (CEST)

Hi,

what kind of certificate do you have? Official, selfsigned? I have one
from CACert and I wonder if that is the problem...

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

Re: TLS errors with GMX/web.de

[Heiko Wundram]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 20.08.2013 12:12, schrieb Sebastian Wiesinger:
> * Heiko Wundram  [2013-08-20 12:09]:
>> Still delivers fine for me (and my mail-server) running Postfix 
>> 2.10.1:
>> 
>> Received: from mout.web.de (mout.web.de [212.227.15.3]) (using 
>> TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No 
>> client certificate requested) by mail.modelnine.org (Postfix) 
>> with ESMTPS id 8854E3640A for ; Tue, 20 
>> Aug 2013 08:35:39 +0200 (CEST)
> 
> what kind of certificate do you have? Official, selfsigned? I have 
> one from CACert and I wonder if that is the problem...

Official certificate by StartSSL on this host, but I'm also getting
inbound mail from web.de without problems on other systems that have
self-singled certificates and do offer STARTTLS.

I'd rather take a guess that your SSL library doesn't advertise a
cipher spec that's accepted by the web.de servers (although I wouldn't
know about restrictions they impose) - you might also simply want to
try and test whether openssl s_client has anything to say about your
exposed configuration.

Anyway, testing mx.karotte.org from mail.modelnine.org seems to show
that the connection should work in principle (I'm getting the same
results as to SSL session negotiation as when I'm connecting to my MX):

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384

except for the fact that my key is 2048 bits, and yours is 1024 bits.

- -- 
- --- Heiko.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSE0PuAAoJEDMqpHf921/SoWoIAJo5Vz2AJv7d2NJr4C6g88se
8Y/ItWFynoYmWuHmYgKYgmtHnLW7WQFq08k0TDrL1SsNJvc2al0T3cNvqEUTnENZ
UoTsye0rfg6Zp9TIdj85DmmyBkKjKtMBgaEu+aeXB29CR6g5P1FcWIpNbpu1U+Cg
f0pngeVVWGpMZdiCC0cctbROllarFaMQBtX9Cuxw74m92mRkMArDzErsFtB/dc6Z
TSJtbb2BmH0uCduAGcBzrzMHHcP6eULIZgubp6gxGSNddlT+jEMPDTj/N2PPj7pi
gcWk/Eh5eU/QcyeE7Q2kaZmVf5C7AZ70xD2nPFyDU80XUstKTCYXZM9ylFWMQTE=
=PZ2s
-END PGP SIGNATURE-

Re: TLS errors with GMX/web.de

[DTNX Postmaster]

On Aug 20, 2013, at 11:48, Sebastian Wiesinger  
wrote:

> GMX and web.de started an initiative for secure E-Mail made in
> Germany... they turned TLS on.
> 
> But in addition to that bold move the did something else that causes
> the following errors when they try to send mail to my postfix:
> 
> postfix/smtpd[28706]: connect from mout.web.de[212.227.15.14]
> postfix/smtpd[28706]: SSL_accept error from mout.web.de[212.227.15.14]: 0
> postfix/smtpd[28706]: warning: TLS library problem: 28706:error:14094438:SSL 
> routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1256:SSL alert 
> number 80:
> postfix/smtpd[28706]: lost connection after STARTTLS from 
> mout.web.de[212.227.15.14]
> postfix/smtpd[28706]: disconnect from mout.web.de[212.227.15.14]
> 
> Postfix 2.9.6 running on Debian 7.1.
> 
> This error ONLY occurs with their servers. My question is if anyone
> has an idea what could cause this error. My first guess is that they
> check certificates for validity and I only have an CACert certificate.
> Also I would like to know if anyone else sees this on their postfix?
> 
> Currently I've disabled STARTTLS for their mailservers but of course I
> would like to use TLS if possible. Would increasing the tls log level
> reveal additional helpful information?

Same Postfix, same Debian, from yesterday afternoon;

==
postfix/smtpd[25199]: connect from mout.web.de[212.227.15.14]
postfix/smtpd[25199]: Anonymous TLS connection established from 
mout.web.de[212.227.15.14]: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 
bits)
postfix/smtpd[25199]: 3cJRKD6cRCz5G: client=mout.web.de[212.227.15.14]
postfix/smtpd[25199]: disconnect from mout.web.de[212.227.15.14]
==

Self-signed, 2048 bits certificate from our own root. Picks the same cipher and 
TLS version as in Heiko's example, it seems. Perhaps it's your certificate, 
perhaps your Postfix settings? No odd overrides for the defaults anywhere, 
forced cipher suites or anything?

Aside from the certificate and key, these are our only non-default settings;

smtpd_tls_loglevel = 1
smtpd_tls_security_level = may

HTH,
Joni

Re: Issue with a customer running Symantec Messaging Gateway: .dat attachments

[Marcio Merlone]

Em 19-08-2013 18:35, Jeroen Geilman escreveu:

On 08/19/2013 06:24 PM, Marcio Merlone wrote:
I run a mail server for my company with Ubuntu 10.04 LTS and postfix 
2.7.0-1ubuntu0.2 and all my users use Thunderbird ESR. We have a 
customer running Symantec Messaging Gateway and it converts 
attachments of our messages with *special chars* to 
"randombogusfilename.dat" (_not_ winmail.dat!). Their support 
directed me to this Symantec KB which, in short, says "it's not our 
fault", even though they are the only destination where I have 
noticed this:


http://www.symantec.com/business/support/index?page=content&id=TECH19239 
 


Has anyone experienced this or know what's this about and how to 
fix/workaround this? Searched Google but no luck.

(...)

If you're paying for Symantec support, by all means open a trouble 
ticket and force some cooperation for your dollars.
My customer is. Customers are always rigth, by definition. ;) They are 
researching on their side (I hope) with Symantec. But they are not yet 
entirely convinced it's their fault, as the KB above says.


A good start would be full message decodes on both sides (the raw 
message both on the client and in the mailbox), as well as packet 
dumps on both ends, to see how the message was altered in transit (if 
it was.)
It is. If I mail an attachment to my boss and cc my customer, my boss 
gets it correctly but my customer get a .dat attach. Only this customer.


A tcpdump comparison between the client-side and the mailbox-side 
would show if Symantec is correct in that their 
mail-gateway-software-money-making-machine does not alter the message 
in transit, or if it does.
Your and all experience: is there how to workaround (and thus giving my 
customer a hint on how to fix) this behavior of SMG? Will fuzz with 
message encoding on Thunderbird and test what happens, but rather not 
reinvent the wheel.


Thank you all, best regards.

--
*Marcio Merlone*
TI - Administrador de redes

*A1 Engenharia - Unidade Corporativa*
Fone:   +55 41 3616-3797
Cel:+55 41 9689-0036

http://www.a1.ind.br/ 

Re: TLS errors with GMX/web.de

[Sebastian Wiesinger]

* DTNX Postmaster  [2013-08-20 12:57]:
> Self-signed, 2048 bits certificate from our own root. Picks the same cipher 
> and TLS version as in Heiko's example, it seems. Perhaps it's your 
> certificate, perhaps your Postfix settings? No odd overrides for the defaults 
> anywhere, forced cipher suites or anything?
> 
> Aside from the certificate and key, these are our only non-default settings;

I found the problem... In addition to my normal certificate, I had an
EC certificate.

smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt

As soon as I removed that line it started working...

Noone else had a problem with that certificate. For completeness here
is the cert output:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 133035 (0x207ab)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root
Validity
Not Before: Aug 13 11:39:24 2013 GMT
Not After : Aug 13 11:39:24 2015 GMT
Subject: CN=*.karotte.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub: 
04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f:
c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae:
3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be:
93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f:
01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22:
5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52:
73:aa:80:56:81:02:29
ASN1 OID: secp384r1
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage: 
TLS Web Client Authentication, TLS Web Server Authentication, 
Netscape Server Gated Crypto, Microsoft Server Gated Crypto
Authority Information Access: 
OCSP - URI:http://ocsp.cacert.org/

X509v3 CRL Distribution Points: 

Full Name:
  URI:http://crl.cacert.org/class3-revoke.crl

X509v3 Subject Alternative Name: 
DNS:*.karotte.org, othername:, DNS:karotte.org, 
othername:
Signature Algorithm: sha1WithRSAEncryption
 04:ca:17:b7:09:b5:00:e0:9f:ac:9b:25:9f:4b:78:d9:fb:a5:
 ...

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant

[ot] Zen and the art of spam abatement (was: Re: greylisting generates error email?)

[/dev/rob0]

Whilst this subject is of some interest to many or most Postfix 
users, it has departed from being fully on topic here. It would fit 
better on a list like SDLU: 

[Disclaimer: I am a list moderator at SDLU.)

On Sat, Aug 17, 2013 at 10:39:25AM -0700, Grant wrote:
> > [attribution of quotes reconstructed]
rob0:
> > On Sat, Aug 17, 2013 at 12:54:44AM -0700, Grant wrote:
> >> Do you mean there aren't any legitimate servers listed in
> >> zen.spamhaus.org?
> >
> > Zen is a composite list, and indeed it is intended to be safe
> > for widespread use.
> >
> > SBL (Spamhaus Block List) lists IP addresses which are known
> > to be under the control of spammers.
> >
> > XBL (Exploits Block List) lists IP addresses which are actively 
> > spewing bot spam. Legitimate servers are occasionally listed in 
> > XBL, because they meet that condition. Some short time after they 
> > stop their abuse, they are delisted. Typically this is less than 
> > a day.
> >
> > PBL (Policy Block List) lists IP addresses which, according to 
> > the netblock owners, should not normally be sending legitimate 
> > email. Exceptions can be made for hosts with custom PTR upon 
> > request. Many colocation providers submit their networks for PBL, 
> > but removal is easy.
> >
> >> When I switched servers a while back, the new IP
> >> I received was listed on several blacklists and it was a hassle
> >> to get them removed.
> >
> > Far better that you go through that step than the Internet be 
> > exposed to more spam.
> 
> I agree, but the fact is that not everyone will go through that 
> step.

You didn't understand. Those who do NOT get delisted from Zen *will* 
face widespread delivery problems. No hard facts exist (nor could 
valid statistics be collected), and it would vary by that site's 
chosen set of sites they wish to send mail to, but in general I bet 
they're going to have delivery problems for >75% of their mail.

This is speaking from my own experience when moving a server to a 
PBL-listed IP address. Before getting the removal approved, my logs 
were clogged with rejections. It was embarrassing. When I discovered 
the problem I rerouted mail through a nonlisted relayhost until 
delisted.

I have also seen this at exploited sites where I have been called in 
to do the cleanup.

Let them be lazy. If they want to participate in Internet mail, 
they're going to take the time to get removed from PBL.

None of the anti-DNSBL zealots can dispute this fact. In fact, this 
is one of the things they so despise about Spamhaus: they have been 
granted "too much power" by many email administrators, large and 
small.

(I apologise to the "anti-DNSBL zealots" for the name calling. I'm a 
pro-DNSBL and pro-Spamhaus zealot myself. I accept the same label. 
Spamhaus and other DNSBL services have all but eliminated my spam 
problem. I am grateful for that.)

Why have we (TINW) given Spamhaus this power? Do they abuse it? What 
would happen if they did?

Mail administrators support Spamhaus because they have been careful 
and responsible in the exercise of that power. They make our job in 
trying to keep the abuse out of users' mailboxes much easier. Also, 
pre-DATA filtering is safer and more accurate than content-based 
approaches.

There have indeed been suggestions of abuse of power by Spamhaus. 
Many of these suggestions were put forth by spammers and spam
supporters (providers who are willing to sell service to spammers, 
turning a blind eye or making excuses in response to abuse reports.)

I'd say those constitute the majority of complaints, in fact. But to 
be fair, there are other complaints. One I am aware of is the 
Austrian national NIC (dot-AT registry.) Austrian law is demonstrably 
spam-friendly regarding domain registrations.

(I don't care about Austrian law. To a large extent I don't even care 
about laws where I live and where my server is situated. Spam is 
crime, and such crime is not excused by ignorant laws. Any valid law 
which is going to require me to accept and handle spam will also 
reimburse my costs in doing so. None of them do. So I block spam, 
including some CAN-SPAM compliant hosts on my US-based server. The 
You-Can-Spam law doesn't pay to accept spam.)

To answer my final question above, if Spamhaus went overboard and 
became like a SORBS, blocking mail providers who have occasional 
issues with spam, well, I'd relegate them to the same status I did 
SORBS. I consider SORBS' opinion on a client useful, but not enough 
to consider the mail to be spam and worthy of blocking.

I am sure that Spamhaus administrators know this. Thus they are 
careful and responsible.

> > Here's my example postscreen configuration which is intended
> > to be safe and reasonable for most uses:
> > http://rob0.nodns4.us/postscreen.html
> 
> Do you use that config on a commercial mail server?  I don't mean 
> to say that you shouldn't, I'm just wondering if you do.  In a 

Not much. The majority of t

Re: postfix content_filter source address

[Wietse Venema]

Jimmy Stewpot:
> content_filter = smtp:[127.0.0.1]:2500
> 
> [...] However with the same version of Pure Message on a new version
> of Postfix we see that the system is seeing "localhost" as the
> from relay which means it goes through the localhost whitelist in
> the spam policy...

On all systems that I know, a connection TO the loopback network
(127.0.0.1) will appear to come FROM the loopback network. Ditto
for other network interfaces. Same for Solaris, Linux, *BSD.

Maybe the change is in the HOSTNAME that your system reports for
127.0.0.1, for example some systems report localhost and other
systems report localhost.localdomain. That is an /etc/hosts issue.

This is easy enough to verify from the command line.

Wietse

postfix.org down?

[Charles Marcus]

for me at least...

--

Best regards,

*/Charles /*

Re: how to see my_networks check in peer_debug, level 2 or greater?

[Charles Marcus]

On 2013-08-16 5:22 PM, lcon...@go2france.com  wrote:

postconf mail_version
mail_version = 2.3.3 


Good gawd...

The reason no one has responded most likely is because you are using 
such an ancient and most importantly unsupported version.


You need to upgrade...

--

Best regards,

*/Charles/*

Re: postfix.org down?

[btb]

On 2013.08.20 10.23, Charles Marcus wrote:

for me at least...


http://www.downforeveryoneorjustme.com/www.postfix.org

Re: postfix.org down?

[Charles Marcus]

On 2013-08-20 10:29 AM, btb  wrote:

On 2013.08.20 10.23, Charles Marcus wrote:

for me at least...


http://www.downforeveryoneorjustme.com/www.postfix.org


Well, it is back up now for me, so either it was really down for a few 
minutes, or there was some kind of DNS issue local to me...


--

Best regards,

*/Charles/*

transport map not working

[jeffrey j donovan]

Greetings

i have an old osx server that was working fine and I noticed that the transport 
maps listed in the config are not being followed.

I have one domain name and several imap servers. 

first i checked if the format for the map was correct in main.cf , 
hash:/etc/postfix/k12_tm_imap2
I verified that user(s) in question had the correct entry in the map.
us...@mydomain.com  smtp:sub1.mydomain.com:25
us...@mydomain.com  smtp:sub1.mydomain.com:25
us...@mydomain.com  smtp:support.mydomain.com:25
us...@mydomain.com  smtp:elemail.mydomain.com:25

did a postmap 

postmap /etc/postfix/k12_tm_imap2

postfix reload


sent email to user1 , the message re-wrote the header as being local, as if I 
had an incorrect entry. I double checked my transport map and it all points to 
us...@sub1.mydomain.com

sample
Aug 20 10:36:41 imap2 postfix/pipe[3641]: 536D3DC23DA: 
to=, orig_to=, relay=dovecot, 
delay=0.02, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot 
service)

So it's delivering it locally when it should deliver it to the system specified 
in the transport map.

what should I be looking for ? what would stop the transport lookup and deliver 
locally ? is there something that overrides the transport map ?
main.cf on this machine is abnormally huge, most of it is set by default I 
usually adjust very little.

thanks for any insight
-j

postconf -n | grep transport
  
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_relay_transport = $relay_transport
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
best_mx_transport = 
default_transport = smtp
defer_transports = 
fallback_transport = 
fallback_transport_maps = 
local_transport = local:$myhostname
mailbox_transport = dovecot
mailbox_transport_maps = 
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps 
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains 
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps 
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks 
$sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps
relay_transport = relay
transport_maps = hash:/etc/postfix/k12_tm_imap2, 
hash:/etc/postfix/bethsd_tm_imap2
transport_retry_time = 60s
virtual_transport = virtual

Re: postfix.org down?

[Jeffrey 'jf' Lim]

On Tue, Aug 20, 2013 at 10:34 PM, Charles Marcus
 wrote:
> On 2013-08-20 10:29 AM, btb  wrote:
>
> On 2013.08.20 10.23, Charles Marcus wrote:
>
> for me at least...
>
>
> http://www.downforeveryoneorjustme.com/www.postfix.org
>
>
> Well, it is back up now for me, so either it was really down for a few
> minutes, or there was some kind of DNS issue local to me...
>

it was down for a while for me too. Either way, it's back up now, so
no worries? Unless somehow you think that this is an issue to worry
about?

-jf


--
He who settles on the idea of the intelligent man as a static entity
only shows himself to be a fool.

"Every nonfree program has a lord, a master --
and if you use the program, he is your master."
--Richard Stallman

Re: TLS errors with GMX/web.de

[Viktor Dukhovni]

On Tue, Aug 20, 2013 at 01:27:01PM +0200, Sebastian Wiesinger wrote:

> I found the problem... In addition to my normal certificate, I had an
> EC certificate.
> 
> smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt

Though I think OpenSSL will generally detect attempts to configure
a public key (certificate) without a matching private key, you
should check that the private key and certificate match:

(
# Adjust as necessary
certfile=/etc/postfix/certs/cacert-karotte-ec.crt   # cert
pkeyfile=/etc/postfix/certs/cacert-karotte-ec.crt   # private key

# Digest of public key from certificate:
openssl x509 -in ${certfile} -noout -pubkey |
openssl pkey -pubin -outform DER |
openssl dgst -sha1 -c

# Digest of public key from private key:
openssl pkey -in ${pkeyfile} -pubout -outform DER |
openssl dgst -sha1 -c
) | uniq -c

This should output a single digest with a count of "2".

> As soon as I removed that line it started working...

If you're willing to test briefly with the EC certificate re-enabled,
it would be helpful to capture a full packet capture tcpdump (aka
pcap) file with a failed delivery from gmx.de/web.de.  Viewing this
with "wireshark" will show exactly where in the handshake the problem
ocurred and may shed some light on the reason.

After capturing all traffic from the source in question for a period of
time that includes at least one complete failed session, extract just that
session from the capture file by identifying the TCP source port of such a
session and running:

client_source_port=58459 # example adjust to match reality
tcpdump -s0 -r /tmp/full-capture.pcap -w /tmp/session-capture.pcap \
tcp port $client_source_port

The resulting output file should contain just a single TCP session with
three way handshake (SYN, SYN-ACK, ACK) and three-way shutdown
(FIN, FIN, ACK or in some cases either FIN or final ACK may be an RST).

Please post a URL to the binary PCAP file.

> Certificate:
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (384 bit)
> pub: 
> 04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f:
> c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae:
> 3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be:
> 93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f:
> 01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22:
> 5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52:
> 73:aa:80:56:81:02:29
> ASN1 OID: secp384r1

There are no known practical attacks on 256-bit EC keys and 384-bit
EC is slower.  AES-128 with EC-256 is sufficiently secure for SMTP
TLS.  Though I expect that if the sender has trouble with 384-bit
EC, they'll have trouble with EC in general.

-- 
Viktor.

Re: transport map not working

[Viktor Dukhovni]

On Tue, Aug 20, 2013 at 10:45:44AM -0400, jeffrey j donovan wrote:

> Aug 20 10:36:41 imap2 postfix/pipe[3641]: 536D3DC23DA: 
> to=, orig_to=, relay=dovecot, 
> delay=0.02, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (delivered via 
> dovecot service)

As documented, transport resolution happens after address rewriting.  So
you need to change the virtual alias (or other) rewrite rules that rewrite
this recipient to user1@imap2.$mydomain.

http://www.postfix.org/ADDRESS_REWRITING_README.html

-- 
Viktor.

Re: postfix.org down?

[Wietse Venema]

Charles Marcus:
> for me at least...

Try www.postfix.org.

Wietse

Re: transport map not working

[Wietse Venema]

jeffrey j donovan:
> Aug 20 10:36:41 imap2 postfix/pipe[3641]: 536D3DC23DA: 
> to=, 

That is us...@imap2.mydomain.com.

> us...@mydomain.com  smtp:sub1.mydomain.com:25

That is not us...@imap2.mydomain.com

You need to update your virtual aliases or your transport map.

Wietse

Re: transport map not working

[jeffrey j donovan]

On Aug 20, 2013, at 11:08 AM, wie...@porcupine.org (Wietse Venema) wrote:

> jeffrey j donovan:
>> Aug 20 10:36:41 imap2 postfix/pipe[3641]: 536D3DC23DA: 
>> to=, 
> 
> That is us...@imap2.mydomain.com.
> 
>> us...@mydomain.com  smtp:sub1.mydomain.com:25
> 
> That is not us...@imap2.mydomain.com
> 
> You need to update your virtual aliases or your transport map.
> 
>   Wietse

thanks for the reply,

I do have a virtual alias map that i am using for some redirected mail list. is 
it because i have no user entry that it delivers locally ? i thought that it 
would step down to transport if it did not find anything.

virtual_alias_maps = hash:/etc/postfix/virtualmm

systemtest...@smtp1.mydomain.comsystemtest...@news.mydomain.com
adminsu...@smtp1.mydomain.com   adminsu...@news.mydomain.com
asapacker-st...@smtp1.mydomain.com  
asapacker-st...@news.mydomain.com
basd-allst...@smtp1.mydomain.combasd-allst...@news.mydomain.com


which I believe comes before transport.
Do I need to add entry's for the user into the virtual_alias_maps & 
transport_maps ? or will one be okay.

this would make sense because I did not have this virtual map before. it is a 
recent add.
thanks for the help.
-j

Re: postfix.org down?

[Charles Marcus]

On 2013-08-20 11:09 AM, wie...@porcupine.org (Wietse Venema) 
 wrote:

Charles Marcus:

for me at least...

Try www.postfix.org.


I did, it was down for about 2 or 3 minutes. By the time someone else 
responded, it was back up.


One other person said it was down momentarily for them too, so it most 
likely wasn't a local problem on my end.


No worries though...

--

Best regards,

*/Charles/*

Re: transport map not working

[Wietse Venema]

jeffrey j donovan:
> I do have a virtual alias map that i am using for some redirected
> mail list. is it because i have no user entry that it delivers
> locally ? i thought that it would step down to transport if it did
> not find anything.
> 
> virtual_alias_maps = hash:/etc/postfix/virtualmm
> 
> systemtest...@smtp1.mydomain.com  systemtest...@news.mydomain.com
> adminsu...@smtp1.mydomain.com adminsu...@news.mydomain.com
> asapacker-st...@smtp1.mydomain.com
> asapacker-st...@news.mydomain.com
> basd-allst...@smtp1.mydomain.com  basd-allst...@news.mydomain.com

If you rewrite an envelope recipient address X with virtual_alias_maps
(or otherwise) into envelope recipient address Y, then Postfix will
use envelope recipient address Y for transport map lookups.

Therefore you will use envelope recipient address Y on the transport
map left-hand side, not X.

Wietse

Re: transport map not working

[jeffrey j donovan]

On Aug 20, 2013, at 11:39 AM, wie...@porcupine.org (Wietse Venema) wrote:

> If you rewrite an envelope recipient address X with virtual_alias_maps
> (or otherwise) into envelope recipient address Y, then Postfix will
> use envelope recipient address Y for transport map lookups.
> 
> Therefore you will use envelope recipient address Y on the transport
> map left-hand side, not X.
> 
>   Wietse

got it.

it works now.
i adjusted my virtual alias map and added the users to it. 

Aug 20 11:47:54 imap2 postfix/smtp[7793]: E898BDC42FD: 
to=, orig_to=, 
relay=sub1.mydomain.com[10.1.1.1]:25, delay=0.04, delays=0.01/0.01/0.01/0.01, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as F116F122AFBF)

question --
If I do not use a virtual alias map, is a transport map sufficient by itself or 
should I always use the two together ? I only ask this because this was working 
before I added the alias map. I just want to be clear that these two work 
together.

thanks again
-j

Re: transport map not working

[Wietse Venema]

jeffrey j donovan:
> If I do not use a virtual alias map, is a transport map sufficient
> by itself or should I always use the two together ? I only ask
> this because this was working before I added the alias map. I just
> want to be clear that these two work together.

That depends.

First, Postfix needs to know what domains to receive mail for
(otherwise mail is rejected with "relay access denied").  You specify
each domain in one of the four domain lists: mydestination,
relay_domains, virtual_alias_domains, or virtual_mailbox_domains.

Then, Postfix needs to know what recipients exist in those domains
(otherwise mail is rejected with "user unknown"). Depending on the
domain list, you specify the recipient in one of the corresponding
recipient lists: local_recipient_maps, relay_recipient_maps,
virtual_alias_maps or virtual_mailbox_maps.

All the above is detailed on ADDRESS_CLASS_README.

If the recipient is does not exist in any of the four recipient
lists, then you must specify them in virtual_alias_maps.

(this is approximate; I have left out canonical mapping to avoid
overwhelming you with detail).

Wietse

Re: transport map not working

[jeffrey j donovan]

On Aug 20, 2013, at 12:17 PM, Wietse Venema  wrote:

> That depends.
> 
> First, Postfix needs to know what domains to receive mail for
> (otherwise mail is rejected with "relay access denied").  You specify
> each domain in one of the four domain lists: mydestination,
> relay_domains, virtual_alias_domains, or virtual_mailbox_domains.
> 
> Then, Postfix needs to know what recipients exist in those domains
> (otherwise mail is rejected with "user unknown"). Depending on the
> domain list, you specify the recipient in one of the corresponding
> recipient lists: local_recipient_maps, relay_recipient_maps,
> virtual_alias_maps or virtual_mailbox_maps.
> 
> All the above is detailed on ADDRESS_CLASS_README.
> 
> If the recipient is does not exist in any of the four recipient
> lists, then you must specify them in virtual_alias_maps.
> 
> (this is approximate; I have left out canonical mapping to avoid
> overwhelming you with detail).
> 
>   Wietse

much thanks for the clarification. Where does the transport map fit in ?
I think you mentioned it before " use envelope recipient address Y on the 
transport
map left-hand side". Ill assume that if i specify a virtual user that i also 
need to specify a transport for that entry, is that a correct assumption ?

-j

Re: transport map not working

[Wietse Venema]

jeffrey j donovan:
> > First, Postfix needs to know what domains to receive mail for
> > (otherwise mail is rejected with "relay access denied").  You specify
> > each domain in one of the four domain lists: mydestination,
> > relay_domains, virtual_alias_domains, or virtual_mailbox_domains.

In addition, mail for $mydestination is given to $local_transport,
mail for $relay_domains is given to $relay_transport, and mail for
$virtual_mailbox_domains is given to $virtual_transport.  Other
mail is given to $default_transport, or returned as undeliverable.

The transport map is needed ONLY when Postfix chooses one of
($local_transport, $relay_transport, $virtual_transport,
$default_transport) and you want it to be different. 

If this is an issue with all recipients in the same domain, then
you have put that domain in the wrong domain list (and recipient
list as outlined in the next paragraph).

Wietse

> > Then, Postfix needs to know what recipients exist in those domains
> > (otherwise mail is rejected with "user unknown"). Depending on the
> > domain list, you specify the recipient in one of the corresponding
> > recipient lists: local_recipient_maps, relay_recipient_maps,
> > virtual_alias_maps or virtual_mailbox_maps.
> > 
> > All the above is detailed on ADDRESS_CLASS_README.
> > 
> > If the recipient is does not exist in any of the four recipient
> > lists, then you must specify them in virtual_alias_maps.
> > 
> > (this is approximate; I have left out canonical mapping to avoid
> > overwhelming you with detail).
> 
> much thanks for the clarification. Where does the transport map fit in ?

disable ipv6 when sending to gmail ?

[Nicolas KOWALSKI]

Hello,

The gmail smtp server is now refusing mails from my system when IPv6 is 
used, as shown in the log below:

Aug 20 06:25:08 petole postfix/smtp[27705]: Trusted TLS connection established 
to gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25: TLSv1.2 with cipher 
ECDHE-RSA-RC4-SHA (128/128 bits)
Aug 20 06:25:09 petole postfix/smtp[27705]: 9E2994012F: 
to=, 
relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b]:25, delay=1.7, 
delays=0.17/0.1/0.78/0.64, dsn=5.7.1, status=bounced (host 
gmail-smtp-in.l.google.com[2a00:1450:400c:c03::1b] said: 550-5.7.1 
[2a01:e35:8ae7:65f0::2  16] The sender does not meet basic ipv6 550-5.7.1 
sending guidelines of authentication and rdns resolution of sending 550-5.7.1 
ip. Please review 550 5.7.1 https://support.google.com/mail/answer/81126for 
more information. l8si5663122wiv.72 - gsmtp (in reply to end of DATA command))

I am not able to have an IPv6 rDNS record with my ISP, only an IPv4 one. 
I guess this is why it works when using IPv4 (tested by forcing 
inet_protocols = ipv4), and does not work any more with IPv6.

Is it possible to have outgoing mail to gmail (or another domain) sent 
using my IPv4 interface?

Thanks,
-- 
Nicolas

Re: disable ipv6 when sending to gmail ?

[Wietse Venema]

Nicolas KOWALSKI:
> I am not able to have an IPv6 rDNS record with my ISP, only an IPv4 one. 
> I guess this is why it works when using IPv4 (tested by forcing 
> inet_protocols = ipv4), and does not work any more with IPv6.
> 
> Is it possible to have outgoing mail to gmail (or another domain) sent 
> using my IPv4 interface?

/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
gmail.com   smtp-ipv4:

/etc/postfix/master.cf:
smtp-ipv4  unix  ..  .. .. ..   smtp
-o inet_protocols=ipv4

# postmap /etc/postfix/transport
# postfix reload

For more automatic kludge, you could try to match the server reply
(with your IP address or other distinctive text), and replace "5XX
SPACE text" with "4XX SPACE text":

/etc/postfix/main.cf:
smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter

/etc/postfix/smtp_reply_filter:
# Postfix uses the last reply code in a multi-line reply.
/^5(\d\d .*your:ipv6:addr:here.*)/  4$1

Then, Postfix will try to deliver to a different IP address.

Wietse

Re: Issue with a customer running Symantec Messaging Gateway: .dat attachments

[LuKreme]

On 20 Aug 2013, at 05:21 , Marcio Merlone  wrote:
> Em 19-08-2013 18:35, Jeroen Geilman escreveu:
>> On 08/19/2013 06:24 PM, Marcio Merlone wrote:
>>> I run a mail server for my company with Ubuntu 10.04 LTS and postfix 
>>> 2.7.0-1ubuntu0.2 and all my users use Thunderbird ESR. We have a customer 
>>> running Symantec Messaging Gateway and it converts attachments of our 
>>> messages with *special chars* to "randombogusfilename.dat" (_not_ 
>>> winmail.dat!). Their support directed me to this Symantec KB which, in 
>>> short, says "it's not our fault", even though they are the only destination 
>>> where I have noticed this:
>>> 
>>> http://www.symantec.com/business/support/index?page=content&id=TECH19239
>>> Has anyone experienced this or know what's this about and how to 
>>> fix/workaround this? Searched Google but no luck.
> (...)
> 
>> If you're paying for Symantec support, by all means open a trouble ticket 
>> and force some cooperation for your dollars.
> My customer is. Customers are always rigth, by definition. ;) They are 
> researching on their side (I hope) with Symantec. But they are not yet 
> entirely convinced it's their fault, as the KB above says.

Interesting. That is one of the most worthless KBs I've ever seen. There is no 
explanation at all and no indication as to what they think incorrectly 
constructed emails are. So, I'll make a WAG that fits in with my (deservedly 
low) opinion of Symantec:

"We get confused by things like UTF-8 and, really, any character encoding that 
is not based on obsolete Windows code pages, so we declare by fiat that all 
these messages are 'incorrect' and shove them into an attachment because we are 
incompetent fools who cannot be bothered to work well with anyone else."

I don't *know* that is the reason, but I suspect (highly) I'm on the right 
track.

>> A good start would be full message decodes on both sides (the raw message 
>> both on the client and in the mailbox), as well as packet dumps on both 
>> ends, to see how the message was altered in transit (if it was.)

> It is. If I mail an attachment to my boss and cc my customer, my boss gets it 
> correctly but my customer get a .dat attach. Only this customer.

What is in the .dat file? How is the message you sent encoded? Maybe they can't 
figure out mime? uudecode?

>> A tcpdump comparison between the client-side and the mailbox-side would show 
>> if Symantec is correct in that their 
>> mail-gateway-software-money-making-machine does not alter the message in 
>> transit, or if it does.

> Your and all experience: is there how to workaround (and thus giving my 
> customer a hint on how to fix) this behavior of SMG? Will fuzz with message 
> encoding on Thunderbird and test what happens, but rather not reinvent the 
> wheel.

You need to get one of these dat files and see what it contains, exactly, and 
compare that to the message you sent (and then to a copy of the message you 
send to, say, a gmail account. There is a chance, albeit a vanishingly small 
chance, that Symantec are technically correct.

Well, no, not really.

-- 
I AM ZOMBOR! (kelly) ZOMBOR!

Using Postfix as a client to an upstream server

[Rob Tanner]

Is it possible to use Postfix as a client to an upstream server?  And by a 
client I mean, can Postfix use auth SMTP to authenticate to that upstream 
server and can it use STARTTLS while acting like a client to the upstream 
server?

If any of the above questions are "yes" i there specific documentation or a how 
to available anywhere on the net?

Thanks,

Rob Tanner
rtan...@linfield.edu

Re: Using Postfix as a client to an upstream server

[Wietse Venema]

Rob Tanner:
> Is it possible to use Postfix as a client to an upstream server?
> And by a client I mean, can Postfix use auth SMTP to authenticate
> to that upstream server and can it use STARTTLS while acting like
> a client to the upstream server?
>
> If any of the above questions are "yes" i there specific documentation
> or a how to available anywhere on the net?

Yes. 

http://www.postfix.org/SOHO_README.html
http://www.postfix.org/SASL_README.html
http://www.postfix.org/TLS_README.html

Wietse