| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> http://rafb.net/paste/results/WoEw3L19.html No corresponding logs in postgresql log, and I had done a restart of postfix to make sure there was not stale db handle
<1> kerneld: telnet to port 25, write "ehlo something" and show the result
<1> is there anyone who used bounce_notify_recipient setting ?
<0> http://rafb.net/paste/results/HbPCcr13.html
<0> mr-k: Looks OK to me
<0> Whats the plain text syntax to test a Login via smtp?
<1> kerneld: plz turn off md5 methods for a moment
<1> i rember that i had some problems with that
<2> Hmmm.
<0> Okay, I just allowed non tls sasl, and forced evo to use unencrypted, and PLAIN (It was set to use encryp when possible, and plain before) and I get something different.
<0> Now it is doing an odd query
<2> Okay. I need a view point. When using virtual_alias_domains, postfix does not map them to the primary domain before doing recipient verification, does it?
<0> http://rafb.net/paste/results/9Ikt7A88.html not sure where it is getting example.com
<0> no auth attempt
<2> I'm trying to use LDAP, using basically a dc=domain.tld,ou=Local,ou=Mail,ou=Servers,dc=domain,dc=tld, where dc=domain.tld has ***ociatedDomains of all the maps to make, as just FQDN's. How can I get those to process before determining recipient verification
<2> ?
<1> kerneld: great, but user stil isnt authorised ?
<1> kerneld: well.. there is example.com, not user name
<1> kerneld: i dont remember substitution of %letter, check if u have it right in smtpd.conf
<3> kerneld: http://www.postfix.org/SASL_README.html#server_test
<1> kerneld: i mean this: sql_select: select p***word from users where email='%u@%r'
<0> mr-k: Pulled from a howto ;)
<1> kerneld: but.. look on log file: statement: select email from users where email = 'example.com'
<0> those substitutions are done by postfix, or sasl?
<1> kerneld: sasl, i think
<1> kerneld: but i'm not sure about it
<2> Anyone? ;}
<1> damn.. really no one can help me ? :/
<0> Thanks lunaphyte
<2> using just virtual_alias_maps to do match ***ociatedDomain to dc, gives me Recipient address rejected: User unknown in virtual alias table.
<2> using just virtual_alias_domains gives me: Recipient address rejected: User unknown in virtual alias table.
<1> damn.. ok, i'm giving up:/
<0> Hmm can't find the sasl conf files as a subdir of cwd of smtpd
<4> sooo.... postfix/virtual craters on AFS
<1> bye all
<0> Psi-Jack: the domain may you have @source @dest ?
<0> or without the @
<2> Without the @
<4> sane_link() appears to be the culprit .. I actually expect it to break in more then just postfix/virtual really, but so far that has been the only instance I have seen it have issues with
<2> Mostly, I'm trying to take, for example, mail.domain.tld and map it to domain.tld, then do recipient verification with the newly mapped domain. :)
<2> I'm beginning to wonder if I should do a canonical_map
<2> Which also.. Did not work. It took it, though, but bounced it. LOL
<5> please help I have multiple bouncing mails, every minute I recieve 4 mails, how can I limit this mails or block the bouncing mails from this sender?
<2> kerneld: Any thoughts? :)
<4> so, does anyone know of any logical reason not to wrap sane_link into a rename() op?
<0> Psi-Jack: Have you tried with @ in the mapping?
<0> I followed http://workaround.org/articles/ispmail-sarge/
<0> working well except for smtp-auth
<2> kerneld: I'm trying to avoid doing that, because the same LDAP information is also being used to handle mydestination and all.
<2> It does, however, at least work, using @domain. :/
<0> :/
<0> brrr its cold
<0> Must be 17C in the office
<2> Okay. One solution I got is a bit annoying. Doing an ldap search filter using %d, instead of %s, and having a cn do the @domain.tld
<2> Dirty hack, though. :/
<4> so no feedback on the link/unlink vs rename scenerio huh?
<4> or is this not a channel for dev?
<2> major: Dev? As in programming?
<4> yah .. as in code
<2> Looks like it. Try the postfix mailing lists.
<6> what's the scenario major ?
<4> mjt, the use of link/unlink in the maildir utility library over rename
<4> mjt, its .. causing me issues
<4> curious as to why link/unlink was chosen over using rename
<4> and or why at least errno wasn't checked on a link failure for an xdev error
<6> because that was the original definition of maildir
<6> you have to ensure the filename is really unique
<4> uhm
<6> with rename the old file will be silently removed
<4> so .. like I was saying
<4> why not using rename()
<6> with rename the old file will be silently removed
<6> per POSIX definitions
<4> hmmm
<4> but the link failure inhibits the delivery from occuring to begin with right?
<6> rename("a", "b") -- if b exist, it will be removed atomically
<4> there isn't any error catching code that is handling this either way
<4> uhm ..
<4> hmm
<4> cl***ic
<4> using link is non-portable to AFS
<6> in other words, AFS isn't POSIX compilant
<6> this topic has been discussed several times on the postfix-users ml
<6> always with the same conclusion
<6> (which is, that AFS isn't supported)
<4> impressive
<6> this uniquines thing may look.. paranoic, because the algorithm used to choose that name is already ensures it's unique
<4> technically supporting links through directories is optional according to SUSv3/POSIX 200x specification if I read this correctly
<4> mind you
<6> but the thing is: this is the way how maildir is defined
<4> technically the ps command is also optional
<4> and the pax command is not optional
<4> it seems a bit silly yes
<6> i'm not arguing with you. i'm jut stating the reasons why it has been done this way. not my reasons.
<4> its humerous that people chose to use POSIX as a basis at all when a good majority of the tools they use, and develope, are not "posix compliant"
<4> wow .. I need a spell checker in my irc client
<4> hehe
<4> humerous, postfix doesn't use pathconf() information at all to find out what the filesystem supports
<4> hmmm
<2> Alright!
<2> Finally getting somewhere. :D
<2> But it's still a bad dirty hack. :/
<0> grr, I need glove. Fingers are cold
<7> Hello
<4> mjt, thank you for the information.
<4> I suppose I will just add an errno check to the maildir utilities and wrap it up in an ifdef AFS then
<6> if you'll try to convince Wietse... mind you, it will not be trivial ;)
<7> http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient - How do you add those lines into the main.cf file, or is it exactly as shown?
<6> from my point of view, just rename() is sufficient
<4> I am not honestly in the mood to convince people :) Your answer was to the point and should have been obvious had I thought about it outside of the scope of the unique filenames
<4> at current I am relying on maildrop as .. oddly, it does support an --enable-afs option at compile time for this situation
<4> unfortunately, it doesn't handle delivery to virtual domains very well that I can tell .. especially not when the domains are comming from ldap
<7> nm, I /think/ I found the answer
<6> major: looks like you know C.. it's a matter of 20 minutes to write a tiny program to deliver mail to a named maildir
<6> major: and having that, you can use transport map that maps recipient to vmail:directory/
<6> where vmail is a pipe transport defined in master.cf that calls your program with $nexthop as the only argument
<4> hmm
<4> yah, I know C .. I don't understand the master.cf well enough to follow what you just said completely
<4> :)
<4> I ***ume $nexthop becomes the destination directory
<6> the only prob with this approach is that all maildirs will be owned by the same user
<4> oddly .. not a problem
<4> afs acl's don't care
<4> :)
<4> the files would be owned by the afs id that resolved to the process either way
<7> is reject_unauth_pipelining a worthy thing to block?
<7> or will it cause problems?
<6> Braden9: it will not cause problems, but it's mostly useless by its own
<6> Braden9: it catches alot of spambots when used with a small delay. like smtpd_client_restrictions = sleep 5, reject_unauth_pipelining (with smtpd_delay_reject=no). But don't do just that - it's not *that* simple... ;)
<6> major: $nexthop is from transport_maps: it's recipient => transport:nexthop
<6> major: this is my favorite trick ;)
<4> mjt, hmmmm
<6> there's ofcourse another way, which may be more "traditional"
<6> the idea is: you set up virtual_mailbox_maps to return the maildir for a given rcpt.
<6> er.. nope it will not work ;)
<6> so it (the original idea, ie my favorite one ;) looks like. You define your domains as relay_domains (not virtual_*). You define a map, say, route_maps (analogous to virtual_maps, transport_maps etc), which return this vmail:directory for recipient. You use it BOTH in transport_maps and relay_recipient_maps. And you define pipe-based transport that uses $nexthop information.
<4> hnn
<4> hmm
<4> maybe
<4> could just patch virtual as well .. seems like less work ;)
<6> that will be alot more efficient
<6> i used my own delivermaildir program to do some more stuff with mails when delivering to maildir.
<6> and i used it exactly that way i described.
<6> "to do some more stuff" means patching virtual wasn't an easy option
<2> Curious, anyone here know much about LMTP?
<6> there's nothing in it to "know much"
<2> I'm wondering, if LMTP can use MX records similarly to SMTP, for setting up multiple possible LMTP deliveries.
<6> care to read the manpage? :)
<2> The LMTP client does not perform MX (mail exchanger)
<2> D'OH!
<2> That would actually be a very ingenious way to handle multiple lmtp points. :)
Return to
#postfix
or
Go to some related
logs:
#oe
forward x11 to third host
gentoo hangs at coldplugging pci devices
dhcpcd prepend
libfglrx gentoo
#math
#kde
chroot /mnt/gentoo Exec format error
apt-get install zlib-dev
#oe
|
|