receipient_delimiter change

2009-08-04 Thread Hose
Hi,

We currently use the default recipient_delimiter of '+', but I've been
receiving requests to change it to a '.' as some sites will not
sanity-check properly with the plus, but will do it with the period.  Is
there an easy way to migrate from one to the other such as enabling both
as a delimiter, or will I just have to go have all the users change
their registered email addresses on the various sites they've registered
their '+' emails on?

hose


something+em...@example.com

2009-01-23 Thread hose
Can anyone tell me what the formal name of the email technique of  
placing something + a delimiter + your email is?  I can't seem to  
remember...


hose


Re: Submission port SSL issues

2009-01-14 Thread hose


On Jan 14, 2009, at 7:01 AM, Neil wrote:


On Tue, Jan 13, 2009 at 7:49 PM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:

On Tue, Jan 13, 2009 at 06:35:24PM -0800, Neil wrote:


I followed Noel's suggestion (top part of master.cf below), but I
still can't get it to work.


I read the above, but I still can't see any information there. I  
think

the word's can't, it and work need to each be replaced by a few
paragraphs explaining clearly to non-psychics what you tried to do,
what you expected to happen, and what actually happened.

--
  Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
mailto:majord...@postfix.org?body=unsubscribe%20postfix-users

If my response solves your problem, the best way to thank me is to  
not
send an it worked, thanks follow-up. If you must respond, please  
put

It worked, thanks in the Subject so I can delete these quickly.



I'm going to spare you a re-hashing of the problem (unless you really
want it); the short of it was I was still having the SSL troubles from
my original post.

After following Noel's why-didn't-I-see-that advice, the continued
error turned out to be that Mail.app was just being too smart for it's
own good.  Seeing as it gives me the same damned error no matter the
problem wasn't very helpful of it either.  Switching over to Tb for
the bulk of my testing (it actually shows the server's response!)
helped me come to the conclusion that Mail.app's
I'll-find-the-best-port-for-you! feature wasn't too good at finding
the best port...

Specifically: Mail.app only does SSL, not TLS.  It would test port 567
for connectivity, but not SSL-ability, for some reason, during
connection tests; and then would decide that, since it was open and
displaying a banner, 567 was the right port to use.  Then, when it
tried to send a mail, with SSL enabled, it would fail because, as you
explained, you can't have SSL and STARTTLS on the same port (and 567
was configured with STARTTLS, as per Postfix's pseudo-defaults).  Long
story short, telling Mail.app to shove it and do it my way (use port
465 all the time) did the trick.  I'm not really sure where in the
auto-configuration process it got stuck on trying 567 first (I believe
there might be circumstances where it will do the right thing
sometime, because it seemed to last time I configured it), but
frankly, I don't really care at this point.

It'd be nice if they added TLS support to Mail.app though.  And were a
little more thorough in their connection tests.


I'm not sure why your Mail.app doesn't support TLS, as mine does it  
find on port 25 with STARTTLS (port 25 also does regular incoming SMTP  
without it).  It also works with SSL on 587, as I've been at places  
using that port and it finds it automatically when port 25 doesn't do  
STARTTLS.  This required no configuration change from the default  
selection of Use Default Ports (25, 465, 587) in the SMTP section of  
the account settings.


hose