On Wed, Mar 25, 2015 at 07:38:58AM +0100, Per Jessen wrote:

Linda Walsh wrote:

...

For some reason, I am unable to send mail to the dell.com based lists: The returned message:

The original message was received at Thu, 19 Mar 2015 16:02:35 -0700 from Athenae [192.168.4.12]

----- The following addresses had permanent fatal errors ----- <mailman@dell.com> (reason: 403 4.7.0 TLS handshake failed.)

----- Transcript of session follows ----- <mailman@dell.com>... Deferred: 403 4.7.0 TLS handshake failed. Message could not be delivered for 5 days Message will be deleted from queue

Reporting-MTA: dns; Ishtar.hs.tlinx.org Arrival-Date: Thu, 19 Mar 2015 16:02:35 -0700

Final-Recipient: RFC822; mailman@dell.com Action: failed Status: 4.4.7 Remote-MTA: DNS; smtp2.ins.dell.com Diagnostic-Code: SMTP; 403 4.7.0 TLS handshake failed. Last-Attempt-Date: Tue, 24 Mar 2015 16:20:21 -0700

What's this about a TLS handshake? I've never seen this type of error before -- I've sent email to their lists before, but now.. nada.. The above fail was trying to send to their list admin.

I'm still getting email *from those lists*, just can't post to them.

Anyone seen this before, or know why it might have cropped up recently (i.e. my openssl and ca's were recently upgraded to 13.2 -- but can't figure out why only one list-host...

Is there any reason why your mailserver (Ishtar.hs.tlinx.org) would want to start TLS with "smtp2.ins.dell.com" ?

Which distribution? but I can reproduce with 13.2: openssl s_client -connect smtp2.ins.dell.com:25 -starttls smtp -bugs This is a SSL PADDING extension problem :/ Which mailserver do you use? Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi Linda, I was mostly wondering what mailserver program and openssl version you use. I am now assuming sendmail and whatever we released as openssl online updates for 13.1/13.2. The problem described is real, and related to the SSL PADDING extensions that was introduced in 1.0.1g. :( Ciao, Marcus On Wed, Mar 25, 2015 at 03:17:13PM -0700, Linda Walsh wrote:

Marcus Meissner wrote:

...

Which distribution? -- I can answer that with 13.1+13.2, and you might say such a mix is unsupported, however, I would equally ask, which, of the many updates, of the various packages is one using?

I encountered this after upgrading my openssl package from 13.1->13.2, but I have yet to update my sendmail package, since that is more of a pain.

I *didn't* have my "ca" list updated, but in looking for causes for this, I updated my "ca" packages to 13.2. Then I ran into weird permission problems trying to regenerate the .db files -- but got weird problems there -- some of the files in that dir had the execute bit set, and the "makemap" program wouldn't run or change such files, Example: /etc/mail/auth/auto-info had permissions 700 (owned by root). The makemap prog said an executable was not allowed.

But file said:

/etc/mail/auth/auth-info: ASCII text

It really was complaining about the 'x' bit being set for 'root' -- even though makemap's handling of the file is only as a 'text file'. The 'x' bit should make no difference, but it refused to run.

That sendmail version: sendmail-8.14.7-92.2.1.x86_64 (included in 13.1).

When I updated my ca-certs packages: 1:ca-certificates-1_201403302107-8.################################# [ 50%] p11-kit: imapd-192.168.3.1.pem: BEGIN ...: unsupported pem block in store p11-kit: imapd-mail.sc.tlinx.org.pem: invalid field line: no colon p11-kit: imapd.pem: BEGIN ...: unsupported pem block in store p11-kit: imapds-192.168.3.1.pem: BEGIN ...: unsupported pem block in store p11-kit: imapds-ishtar.sc.tlinx.org.pem: BEGIN ...: unsupported pem block in store p11-kit: imapds-mail.sc.tlinx.org.pem: BEGIN ...: unsupported pem block in store p11-kit: imapds.pem: BEGIN ...: unsupported pem block in store --repeated 2-3 times--- then... /etc/ssl/certs/A-Trust-nQual-03.pem in the way *) /etc/ssl/certs/AC_Ra_xC3_xADz_Certic_xC3_xA1mara_S.A..pem in the way *) /etc/ssl/certs/ACCVRAIZ1.pem in the way *) ... /etc/ssl/certs/XRamp_Global_CA_Root.pem in the way *) /etc/ssl/certs/YaST-CA.pem in the way *) /etc/ssl/certs/A-Trust-nQual-03.pem is in the wrong location *) /etc/ssl/certs/AC_Ra_xC3_xADz_Certic_xC3_xA1mara_S.A..pem is in the wrong locati on *) /etc/ssl/certs/ACCVRAIZ1.pem is in the wrong location *) ... /etc/ssl/certs/YaST-CA.pem is in the wrong location *) 0 added, 0 removed. * = CA Certificates in /etc/ssl/certs are only seen by some legacy applications. To install CA-Certificates globally move them to /etc/pki/trust/anchors instead! p11-kit: imapd-192.168.3.1.pem: BEGIN ...: unsupported pem block in store p11-kit: imapd-mail.sc.tlinx.org.pem: invalid field line: no colon p11-kit: imapd.pem: BEGIN ...: unsupported pem block in store p11-kit: imapds-192.168.3.1.pem: BEGIN ...: unsupported pem block in store ..several more.. -- Thought the installation had failed, but thenL: Ishtar:/var/lib/ca-certificates# rpm --replacefiles -Uhv /suse132/ca-certificates-1_201403302107-8.1.2.noarch.rpm Preparing... ################################# [100%] package ca-certificates-1_201403302107-8.1.2.noarch is already installed

...

---- So I guess they are installed... but it sure didn't encouraging.

Will have to try another email... but I've never 'knowingly' tried to use TLS or SSL on my outgoing mail -- imap access, yes, but outgoing sendmail?... weird.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi, The code did not change, but there is a configuration method: Can you try adjusting your sendmail.cf to have: ServerSSLOptions -SSL_OP_ALL ClientSSLOptions -SSL_OP_ALL This will disable all default work around options including the PADDING one. (Currently cannot test this, my last sendmail installation is long gone ;) Ciao, Marcus On Thu, Mar 26, 2015 at 09:23:43AM -0700, Linda Walsh wrote:

Marcus Meissner wrote:

...

Hi Linda,

I was mostly wondering what mailserver program and openssl version you use.

I am now assuming sendmail and whatever we released as openssl online updates for 13.1/13.2.

The problem described is real, and related to the SSL PADDING extensions that was introduced in 1.0.1g. :(

---

So why would I only get it with (well, that I notice) with one receiver (almost any email going to 'dell.com').

Since I haven't upgraded my sendmail program yet, I'm guessing it has to do with my updating openssl to the current 13.2 version (aka openssl-1.0.1i-2.1.4.x86_64)?

Is there a bug already filed on that (I'd assume? -- don't want to create a 'dup'). What bothered me a bit is that my sendmail automatically started using the "new and improved, faulty transport.

I.e. to me, it seems a bit 'buggy' that sendmail would automatically start using whatever new transport layer is installed -- for exactly situations like this -- where, the new transport layer isn't quite "ready" to be a drop-in replacement....

Any idea how I turn off an auto-upgrade feature like that in sendmail?

BTW -- I don't _exactly_ have the latest online updates installed, I tend to download a copy of the repos, then update local "interdependent" chunks at one time.

I have gotten into too much trouble going for auto-installed updates because I couldn't keep up with all that was changed and couldn't figure out if I broke something or if some new update was causing the problem.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Mar 26, 2015 at 11:53:53AM +0200, auxsvr@gmail.com wrote:

On Wednesday 25 of March 2015 10:49:08 Marcus Meissner wrote:

...

Which distribution?

but I can reproduce with 13.2: openssl s_client -connect smtp2.ins.dell.com:25 -starttls smtp -bugs

This is a SSL PADDING extension problem :/

On oS 13.2, an SSL vhost outputs errors:

AH02259: insecure SSL re-negotiation required, but a pipelined request is present; keepalive disabled AH02261: Re-negotiation handshake failed: Not accepted by client!?

while connections are unreliable. The client is either chromium or owncloud client. Owncloud (Qt5) yields the error message:

Error while reading: error 140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message, error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure

Is this related to the SSL PADDING problem?

This reads like a different problem. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 03/25/2015 02:38 AM, Per Jessen wrote:

...

Is there any reason why your mailserver (Ishtar.hs.tlinx.org) would want to start TLS with "smtp2.ins.dell.com" ?

In general, email is moving to encryption with SSL/TLS.

I'm not sure about the "in general" in that. We process a lot of email daily, 99% is unencrypted. I'd have to check the logs to see whether there's been any growth in TLS usage.

StartTLS is one method of doing that.

It's the only one I know of unless you encrypt the entire network (IPsec, VPN) which doesn't really make sense for email, unless you're on a closed network. -- Per Jessen, Zürich (11.8°C) http://www.spamchek.com/ - managed email services made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

So, all you have to do is enable StartTLS and it will be used when the other end supports it too. -- I don't get the point of doing that -- especially when TLS layer seems to have some problems.

But why encrypt in sending, when most of the time it will be displayed on some mailing list which I still get, and AFAIK, isn't encrypted... If it was encrypted in all transports, *maybe* useful, but services like gmane make such encryption pointless. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/25/2015 2:45 PM, Linda Walsh wrote:

James Knott wrote:

...

So, all you have to do is enable StartTLS and it will be used when the other end supports it too. -- I don't get the point of doing that -- especially when TLS layer seems to have some problems.

But why encrypt in sending, when most of the time it will be displayed on some mailing list which I still get, and AFAIK, isn't encrypted... If it was encrypted in all transports, *maybe* useful, but services like gmane make such encryption pointless.

StartTLS is depriated, and many big ISPs were caught stripping the StartTLS request or reply (i forget which) to force unencrypted mail so to be sent. StartTLS always starts unencrypted. Using proper ports 465,etc and encryption means the mail is either going to be encrypted or it is not going to be sent, and the men in the middle don't get to force TLS off by simply trimming a capability out of the server's reply. Linda, I think your question should be rephrased as "Why should ANY email travel unencrypted?" Give me one good reason. (I'm Not talking about PGP, GPG or any client side encryption, simply transport layer security.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

StartTLS is depriated, and many big ISPs were caught stripping the StartTLS request or reply (i forget which) to force unencrypted mail so to be sent. StartTLS always starts unencrypted. Using proper ports 465,etc and encryption means the mail is either going to be encrypted or it is not going to be sent, and the men in the middle don't get to force TLS off by simply trimming a capability out of the server's reply.

Linda, I think your question should be rephrased as "Why should ANY email travel unencrypted?" Give me one good reason. (I'm Not talking about PGP, GPG or any client side encryption, simply transport layer security.)

For the same reason why garden hoses shouldn't automatically built of water-proof titanium mesh when they are being used to water the public park down the street. The protection of "non-confidential" information on the way to display at the public library (or a public park) is an excess cost, AND might give some people the idea that the email was somehow going to be more confidential or protected. But in the US, courts have already ruled that anytime you send information to (or through) a third party, the information loses protections that would otherwise requires a "subpoena" or "due process of law". Conversely, if I wanted to ensure the sanctity of my information (or water), then such measures are worth the cost and measures against tampering. Similarly if I send a letter to you, talking about the weather or whatever -- just to say hi, I would most likely use a regular envelope. Why pay to have the letter shipped in a safe container. Even more realistic -- if I buy something from overseas, if I have it sent via a metal safe, I might find it arriving with a hole cut in the side of the safe, and the contents "fried". Vs. an unprotected, easy to open box that customs could easily unseal and reseal and allow to go on its way. People coming in through any "checkpoint" (NSA checkpoint for email or customs at country boundaries), are much more likely to be detained if customs can't easily inspect the contents. It's mostly a matter of not going through some hardening procedure that may not work in the first place -- (like the current prob of TLS negotiation that keeps the email from being delivered) -- is the benefit gained by encrypting email to a public list, worth the trouble of email-delivery breakage and the message not getting there at all (on occasion?)... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/26/2015 02:39 AM, robert rottermann wrote:

Unlike with "real" goods, strongboxing emails can be done by using common tools and without real costs..

Precisely. It is the same economic difference bas exists for unsolicited mail between physical mail, the cost of the letter, printing, paper, envelope, stuffing and postage, >$1, probably >$2, vs e-mail, asymptotic zero per 100,000. The cost of TLS is a pull-down option in configuration. The cost of PGP encoding the message is downloading the plugin and 15 minutes setup & posting your public key to a known server. From then on its just flipping an option and entering a passphrase. Negligible compared to a physical strong box. Anything prefixed by "e-" has probably changed the whole economic model. To quote Peter Drucker from his article in "Wired" of 03-MAR-1998 "Current economics is merely refining the obsolete. Economic theory is still based on the scarcity axiom, which doesn't apply to information. When I sell you a phone, I no longer have it. When I sell information to you, I have more information by the very fact that you have it and I know you have it. That's not even true of money." -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 03/25/2015 08:40 AM, Per Jessen wrote:

...

...

In general, email is moving to encryption with SSL/TLS. I'm not sure about the "in general" in that. We process a lot of email daily, 99% is unencrypted. I'd have to check the logs to see whether there's been any growth in TLS usage.

Many email providers are now supporting or even requiring SSL/TLS.

Supporting definitely, but that's not really new. Well, I don't think so, I'm still checking the logs. Requiring TLS - I haven't seen (m)any of those, except those that specifically offer secure services.

...

...

...

StartTLS is one method of doing that. It's the only one I know of unless you encrypt the entire network (IPsec, VPN) which doesn't really make sense for email, unless you're on a closed network.

The other method is to use specific ports for SSL/TLS.

Do you have some info on how that works with any arbitrary email host? I see no support for that in e.g. postfix. It's all STARTTLS. -- Per Jessen, Zürich (5.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 03/26/2015 03:22 AM, Per Jessen wrote:

...

James Knott wrote:

...

On 03/25/2015 08:40 AM, Per Jessen wrote:

...

...

In general, email is moving to encryption with SSL/TLS. I'm not sure about the "in general" in that. We process a lot of email daily, 99% is unencrypted. I'd have to check the logs to see whether there's been any growth in TLS usage.

Many email providers are now supporting or even requiring SSL/TLS. Supporting definitely, but that's not really new. Well, I don't think so, I'm still checking the logs. Requiring TLS - I haven't seen (m)any of those, except those that specifically offer secure services.

IIRC, GMail requires it.

...

...

...

...

...

StartTLS is one method of doing that. It's the only one I know of unless you encrypt the entire network (IPsec, VPN) which doesn't really make sense for email, unless you're on a closed network. The other method is to use specific ports for SSL/TLS. Do you have some info on how that works with any arbitrary email host? I see no support for that in e.g. postfix. It's all STARTTLS.

In Seamonkey & Thunderbird, you can specify connection security with the choices none, starttls and ssl/tls. You can also specify the port number to be used.

Yes, but that is only for mail submission, not for mail exchange between two mail servers. -- Per Jessen, Zürich (7.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/26/2015 7:30 AM, James Knott wrote:

In Seamonkey & Thunderbird, you can specify connection security with the choices none, starttls and ssl/tls. You can also specify the port number to be used.

And I believe both packages offer a Check what the Server supports option. Of course this only affects your first hop to your first MTA. Google, and all the other big email carriers are pretty much at the mercy of the destination MTA (And any intermediate MTAs, although there tend to be non these days). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/25/2015 6:59 AM, James Knott wrote:

...

...

StartTLS is one method of doing that. To clarify, the choices are plain text, specific configuration for SSL/TLS, which requires the other end also be configured for it and a different port number, or StartTLS, which uses the same port numbers as

On 03/25/2015 08:40 AM, Per Jessen wrote: plain text, but TLS is negotiated, when available.

ANY man in the middle can suppress a negotiated TLS when using STARTTLS. All they have to do is strip the server's reply of the STARTTLS capability, or drop your client's request to starttls. Several big ISPs were caught doing this which is why StartTLS is a bad idea. https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 03/25/2015 07:04 PM, John M Andersen wrote:

...

Several big ISPs were caught doing this which is why StartTLS is a bad idea.

My take on that article is that it's still recommended, but with plans to make things more secure. Of course, if the Internet is classified as a utility, then the ISPs may be open to prosecution for tampering with email.

Oh, they are already - ISPs are classed as telecommunications providers subject to the regular Fernmeldegesetz. They are pretty much subject to the same regulations as the Post Office. Tampering with the _exchange_ of the same emails might be another matter. In my business we "tamper" with the exchange all the time - for instance, we disable our own STARTTLS when the other side can't figure out how to work with it, we disable pipelining when it doesn't work, postfix automagically fixes Cisco PIX bugs etc etc. -- Per Jessen, Zürich (5.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 03/26/2015 03:15 AM, Per Jessen wrote:

...

James Knott wrote:

...

...

Several big ISPs were caught doing this which is why StartTLS is a bad idea. My take on that article is that it's still recommended, but with

On 03/25/2015 07:04 PM, John M Andersen wrote: plans to make things more secure. Of course, if the Internet is classified as a utility, then the ISPs may be open to prosecution for tampering with email. Oh, they are already - ISPs are classed as telecommunications providers subject to the regular Fernmeldegesetz. They are pretty much subject to the same regulations as the Post Office.

In some countries, such as the U.S., it's still not considered a utility, though that may be coming soon.

...

Tampering with the _exchange_ of the same emails might be another matter. In my business we "tamper" with the exchange all the time - for instance, we disable our own STARTTLS when the other side can't figure out how to work with it, we disable pipelining when it doesn't work, postfix automagically fixes Cisco PIX bugs etc etc.

I assume you're talking about a mail server and not just an ISP that happens to be carrying the traffic.

In this case yes, but they're often one and the same thing. -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 03/26/2015 09:39 AM, Per Jessen wrote:

...

...

I assume you're talking about a mail server and not just an ISP that

...

happens to be carrying the traffic. In this case yes, but they're often one and the same thing.

That depends.

Sure - I did say "often", not "always".

My main email account is provided by my ISP, but I also have a GMail account. I run my own IMAPS server for my main account. I also have a (yuck) outlook.office365 account for work.

Probably not an all too unusual situation. Anyway, you seem to believe an ISP and a mailhoster are legally in two different situations wrt their treatment of email traffic? Around here, while the access provider does have extra legal requirements, neither one is allowed to tamper with the contents of an email. All due to telecommunications legislation, possibly compounded by data privacy ditto. -- Per Jessen, Zürich (7.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

In this instance, as an email provider, they can enable TLS or not. As an ISP, they're not to tamper with anything passing over their network. The FCC's recent regulatory action (if it survives court challenges) may actually make it

On 3/26/2015 9:42 AM, James Knott wrote: possible to run your own mail server in the US again. If you buy a commercial internet account, some ISPs may condescend to allow you to run your own mail servers again, instead of insisting all outgoing mail go through their servers. The way the internet was supposed to work. (This was largely done away with in an ill conceived attempt at spam fighting). Most large ISPs in the US don't allow ANY listening ports open, and frequently scan for these on consumer plans. Business plans make all that go away. But in many cases, even with fully valid certificates, you still can't send your own email outgoing, without gong through their (or someone's) smtp server because many mail servers do reverse DNS lookups, and arbitrarily decide that your IP is in a block allocated to consumer use, and refuse connections. The new FCC rules address something called an Edge Provider which must not be discriminated against. Web servers, mail servers, game servers seem to fall under that umbrella. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 25 Mar 2015 13:40:36 +0100 Per Jessen <per@computer.org> wrote:

James Knott wrote:

...

On 03/25/2015 02:38 AM, Per Jessen wrote:

...

Is there any reason why your mailserver (Ishtar.hs.tlinx.org) would want to start TLS with "smtp2.ins.dell.com" ?

In general, email is moving to encryption with SSL/TLS.

I'm not sure about the "in general" in that. We process a lot of email daily, 99% is unencrypted. I'd have to check the logs to see whether there's been any growth in TLS usage.

...

StartTLS is one method of doing that.

It's the only one I know of unless you encrypt the entire network (IPsec, VPN) which doesn't really make sense for email, unless you're on a closed network.

When replying to previous messages it would be beneficial for viewers to be able to see the original message context, not the "(...)" which seems to be prevalent on this list. That makes it harder to follow the thread replies. Thanks, Tom -- You don't get to choose how you're going to die, or when. You can decide how you're going to live now. -Joan Baez ^^ --... ...-- / -.- --. --... -.-. ..-. -.-. ^^^^ Tom Taylor KG7CFC openSUSE 13.1 (64-bit), Kernel 3.11.6-4-default, KDE 4.11.2, AMD Phenom X4 955, GeForce GTX 550 Ti (Nvidia 337.19) 16GB RAM -- 3x1.5TB sata2 -- 128GB-SSD FF 36.0, claws-mail 3.10.1 registered linux user 263467 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed 25 Mar 2015 02:58:20 PM CDT, Marcus Meissner wrote:

Hi Linda,

Not sure if you got my other mail, but please open a bugreport.

also include: opensuse version used, mailserver used that sends your email

Ciao, Marcus On Tue, Mar 24, 2015 at 10:00:41PM -0700, Linda Walsh wrote:

...

For some reason, I am unable to send mail to the dell.com based lists: The returned message:

The original message was received at Thu, 19 Mar 2015 16:02:35 -0700 from Athenae [192.168.4.12]

----- The following addresses had permanent fatal errors ----- <mailman@dell.com> (reason: 403 4.7.0 TLS handshake failed.)

----- Transcript of session follows ----- <mailman@dell.com>... Deferred: 403 4.7.0 TLS handshake failed.

Hi I don't know if this is relevant, but helped a user yesterday in the forum trying to relay from a system using gmail and postfix. I have a SLES 11 SP3 system that works, yet on openSUSE 13.2 I had to tweak the master.cf file to un-rem 'tlsmgr' for starttls to work. On the SLES system this is remmed out... -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.38-44-default up 5 days 16:12, 5 users, load average: 0.58, 0.54, 0.48 CPU AMD A4-5150M APU @ 3.3GHz | GPU Richland Radeon HD 8350G -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org