Re: bl.spamcop.net false positives
Something's amiss... First time in 10 years I've gotten this: "An error occurred while processing your request. Reference #30.24721cb8.1612134453.1a374d81" from here: https://www.spamcop.net/ Something has changed. On 2021/01/31 11:13 AM, Gerald Galster wrote: Good news, the nameservers have changed again: [gerry@noc ~]$ whois spamcop.net Domain Name: SPAMCOP.NET Registry Domain ID: 3340109_DOMAIN_NET-VRSN Registrar WHOIS Server: whois.enom.com Registrar URL: http://www.enom.com Updated Date: 2021-01-31T16:04:06Z Creation Date: 1999-01-30T05:00:00Z Registry Expiry Date: 2022-01-30T05:00:00Z Registrar: eNom, LLC Registrar IANA ID: 48 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Name Server: NS1-109.AKAM.NET Name Server: NS1-11.AKAM.NET Name Server: NS1-73.AKAM.NET Name Server: NS1-90.AKAM.NET Name Server: NS1-93.AKAM.NET Name Server: USE1.AKAM.NET Best regards Gerald As of now the issue has not been solved, the same ip is returned: [gerry@noc ~]$ dig +short @DNS5.NAME-SERVICES.COM spamcop.net 91.195.240.87
Re: Usage of posttls-finger
On 2021/01/26 19:49 PM, Viktor Dukhovni wrote: On Tue, Jan 26, 2021 at 07:25:45PM -0500, vi...@vheuser.com wrote: posttls-finger -c -lmay "[example.com]" returns "posttls-finger: Server is anonymous" What should the server return? How it his configured? You can try "-lsecure" instead, this will disable anon-DH ciphers. Shouldn't the server return an identity? How would that be configured?
Usage of posttls-finger
posttls-finger -c -lmay "[example.com]" returns "posttls-finger: Server is anonymous" What should the server return? How it his configured?
Re: Mail server without MX record.
But it helps to know what bait is before you buy a fishing boat. ~v On 2020/10/14 10:00 AM, Wietse Venema wrote: Jason Long: It is so odd that some people here don't like to answer to the users questions and forwarding them to read a book with 496 pages. Indeed, postfix-users is not a cargo-cult recipe factory. Teach a man to fish, and they can feed themselves. Wietse
Re: Postfix mailq priority
On 2020/06/16 13:42 PM, Wietse Venema wrote: vi...@vheuser.com: Obviously I am above my pay grade here, but can this? "Adding some artificial 'cost' value" currently be done? No. There is an existing solution that works for multi-recipient list mail. That solution does not work for single-recipient list mail, which we suspect is your use case. Viktor proposes to schedule single-recipient list mail from the same sender as if it is multi-recipient list mail (post-facto grouping). I'm proposing to just put a cost on each delivery request, initially based on how many other requests a sender already has in flight, that decays over time until the request is selected for delivery. This guarantees that all mail will eventually be delivered. This also would give us the option to make the scheduling dependent on message size, or quality-of-service indicators. Wietse Just fyi - Mailman domain concurrency is a yes/no/full option. I've limited postfix to 5 and set Mailman to yes and that sped things up dramatically with no rejections from TWC.
Re: Postfix mailq priority
On 2020/06/16 10:39 AM, Wietse Venema wrote: Viktor Dukhovni: On Mon, Jun 15, 2020 at 08:25:31PM -0500, Noel Jones wrote: Postfix has only one queue, and concurrency and process count is per-destination, not based on where the mail came from. Consider using a separate postfix instance for delivering mail list messages to prevent them from interfering with regular mail. See MULTI_INSTANCE_README There's one active queue, but within that active queue messages are queued to a particular (transport,nexthop) pair, and scheduling is round-robin by transport, and then FIFO, subject to concurrency and process limits and amortised pre?mption of multi-recipient messages by messages with fewer recipients, so that messages with lots of recipients don't hog the queue too long before some other messages with fewer recipients that arrived later get to use a delivery slot. If one just wants to put messages in multiple "lines" for delivery scheduling, but otherwise all settings are the same, then using multiple transports is simpler and often just as effective as multiple instances. The more Postfix can do by itself, the better. That could be: - Adding layer of sender-based round-robin selection. Not sure if that would explode at large scale. - Adding some artificial 'cost' value that is computed while delivery requests are added to per-destination queues. Cost could depend on the number of delivery requests per sender email address, the message size, and so on. Then, the scheduler could choose what-to-deliver based on artificial cost in addition to the things that it already considers now. Wietse Obviously I am above my pay grade here, but can this "Adding some artificial 'cost' value" currently be done? How?
Re: Postfix mailq priority
On 2020/06/16 11:32 AM, Viktor Dukhovni wrote: On Jun 16, 2020, at 12:39 PM, Wietse Venema wrote: - Adding layer of sender-based round-robin selection. Not sure if that would explode at large scale. When the input mix approximates steady-state, FIFO is essentially optimal, with each type of message getting its average share of the output in a fair and timely manner. If/when we stray from FIFO, we need to be carefuly not be simply underserving some fraction of the expected steady-state load distribution. This would mean being able to somehow detect a "burst" of traffic and characterise to distinguish the messages that are contributing to the burst from other messages. That's a tricky problem. The sender address for bulk traffic is liable to have VERP tags, the client IP of interest may be a few hops back from the edge system that encounters delays in delivering an input burst to remote organizations (ADMDs in the language of RFC5598). - Adding some artificial 'cost' value that is computed while delivery requests are added to per-destination queues. Cost could depend on the number of delivery requests per sender email address, the message size, and so on. Then, the scheduler could choose what-to-deliver based on artificial cost in addition to the things that it already considers now. Ideally we'd have an algorithm that could group related messages into a set of logical "bulk" sources, and apply the current bulk message preëmption algorithm not only to multi-recipient mail, but also to multi-message bulk sources. The hard part is the classification, especially in a single-threaded queue manager that needs to do this in O(1 millisecond). Perhaps the best proxy for related messages is origin domain (ignoring localpart) + approximate message size. Related messages are likely to carry similar content of approximately the same size to all recipients. But completely ignoring the localpart may be too coarse. It is not obvious to me how to extract common elements from a per-recipient-salted localpart... A traditional multi-recipient message automatically qualifies as a single source (same message size for all recipients and same origin domain). We could attempt to group "related" messages in a fuzzy manner as above, and then apply the existing preëmption algorithm. Still not sure how to do a good job of the aggregation. I've got a lot to learn here. Didn't expect so much detail! Ideally, one could flag the big list somehow and not worry about the little ones. I turned off concurrency because TWC.com was rejecting bundles of emails. Serious slow down. Postfix steadily delivers, but would like to de-prioritize the list emails so regular traffic is not delayed. I will look up how to create transports and assign mail to them. But it appears that there would be no way to redirect what is already in the queue. Is that correct? (Sheepish grin) Feature request? (-:
Re: Postfix mailq priority
On 2020/06/15 19:01 PM, Viktor Dukhovni wrote: On Mon, Jun 15, 2020 at 04:50:16PM -0400, vi...@vheuser.com wrote: Is there any way to change the order of delivery of items in the mail queue? Not as such, but see below. Is there any way of changing priority of mail when adding to the queue? Not as such, but: - Mail delivery within a given transport is largely FIFO. - But messages for destinations that have reached their destination concurrency limit (for the transport) are delayed until enough earlier messages are delivered. - Mail delivery is round-robin by transport, but deliveries via transports that have reached their process limit are delayed until free process slots become available. Therefore, you can prioritise some messages by using a dedicated transport that is not congested with other low-priority messages and sends to a destination that is willing to accept messages quickly enough at the configured concurrency. Sometimes a dedicated transport is used to separate sluggish low-priority traffic from normal traffic, so that normal traffic delivery is unimpeded. You get to put messages in different queues, some queues may move faster or slower than others. The express checkout line in a supermarket is great if most shoppers are filling carts, and just a few are grabbing a quick couple of items. But if one day everyone wants a carton of milk and a pack of chewing gum, the express line could turn out to be much slower. Thanks, Viktor. The problem is periodic, completely irregular, mailing list loads. It would be nice to lower the list priority so that regular mail got delivered first. I had to force some lists to lower concurrency but now they clog the queue. Guess I had better read up on alternative transports, but thanks to the response.
Postfix mailq priority
Is there any way to change the order of delivery of items in the mail queue? Is there any way of changing priority of mail when adding to the queue? Searched the docs and found nqmgr but not this specific question. Thank you.
Re: [External] Re: The historical roots of our computer terms
On 2020/06/08 09:31 AM, Kevin A. McGrail wrote: On 6/8/2020 9:06 AM, John Dale wrote: Why does this agitate people? Because if the time spend on this change had been used to fix an actual deficiency, people of color who use the software would have been served with value, not just platitudes. Sounds like a lot of pontificating. Can you back up this stance with your CV related to open source software, please? Are you a committer, contributer, supporter, sponsor or member of any OSS project or OSS organization? Regards, KAM Perfect. The ad hominem argument fits in perfectly with the rest of this drivel. The unrestrained snowflakes seeking to harass everyone else off the list. Can we get back to work or do we all have to unsubscribe because of an abusive few? PS Red-list offends native Americans and Green-list offends environmentalists.
Re: The historical roots of our computer terms
On 2020/06/07 14:13 PM, Charles Sprickman wrote: On Jun 7, 2020, at 2:03 PM, vi...@vheuser.com wrote: Why not take it off this list and contact the developers? Users can't make small changes. Enough already. The intersection of “this is meaningless politics, stop being such a carelord” and “shield my eyes from further discussion of this nonsense” is fascinating. Not sure what all that means, but I am sure that my blacks friends are competent to speak for themselves without self-righteous white carelords condescending to save them.
Re: The historical roots of our computer terms
Why not take it off this list and contact the developers? Users can't make small changes. Enough already. On 2020/06/07 12:59 PM, Pau Amma wrote: On 2020-06-07 18:44, Norton Allen wrote: [undeserved snippage] Someone has suggested that we make a small change, a change that Black people have said would make them feel better, and all we can do is argue that making that change would be too difficult, unnecessary, ineffective or etymologically inaccurate. Is that how you respond when a neighbor asks a favor? Heck, is that how you respond when faced with a technical challenge? Or do you stop for a minute to think about the problem, how it might be manifested in different situations or for different people, and start to try to figure out what you can do to help? *standing ovation* Thank you for posting this.
Re: Postfix -> Whatapp
On 2020/05/26 14:06 PM, Bill Gee wrote: Almost completely irrelevant, but still an interesting (and true!) story ... About 30 years ago I started a job at an insurance company. At that time less than half the company had PCs. Most had 3270 green screen terminals. The corporate email was SYSM running on a System 370 mainframe. Someone had cleverly arranged things so that whenever you got an email, it would send you a voice mail. Fast-forward 25 years: After several acquisitions and many changes of email, the company is now running on Exchange. Someone very clever rigged up a system so that whenever you got a voice mail, it sent you an email. How things go around! -- Bill Gee On Tuesday, May 26, 2020 12:52:13 PM CDT Phil Stracchino wrote: > On 2020-05-26 13:42, Jos Chrispijn wrote: > > Is there a way of Postfix sending a Whatsapp message to a user when > > there came in email for her/him? > > > > Thanks, Jos > > No. That is utterly and totally not Postfix's, or any MTA's, job. Period. > > If you wanted to get a WhatsApp notification when you receive new mail, > you'd need to find a mail *client* that has some kind of WhatsApp > notification plugin. (Good luck with that.) > > > Good story, Bill. Did some of that on a DEC10 myself. Too bad not everyone shares your conviviality. I hate to see folks on a user list throw down at a question. More helpful than "No way, utterly" is "Here's how to". The question was how to initiate a script upon receipt of an email. Here's a suggestion: https://unix.stackexchange.com/questions/178396/run-script-on-receipt-of-email
Re: noreply email technisch und für Empfänger zum Ausdruck bringen
On 2020/05/23 08:11 AM, Viktor Dukhovni wrote: On Sat, May 23, 2020 at 02:02:52PM +0200, Thomas wrote: ich sende ab und an etwas an Ämter vorab. Die kommen mittlerweile sogar mit pdf zurecht! Leider sprechen wir hier (postfix-users) nur Englisch. Deutsch have ich nicht so gut in der Schule gelernt. :-( Es macht nichts. Wir haben alle zugriff auf Google Translate. (-;
