On 7/13/24 00:33, ml+mailop--- via mailop wrote:
If a program just works, why should it be updated?
I've seen two reasons that working code needs to be updated:
1) Moving targets for compiler and tool chain. E.g. contemporary
compiler tool chain can get quite unhappy with sufficiently old c
On 7/12/24 14:57, Jesse Hathaway via mailop wrote:
I had not yet considered it. It looks like there is a milter available,
but it is unmaintained. I would be a little wary of setting it up,
given the lack of maintenance.
:-/
Are there other opensource BATV milters?
It's not BATV but it doe
On 6/28/24 11:00 AM, Al Iverson via mailop wrote:
If you want to trust me with the person's email address, I'll pass it to
a bunch of ESP deliverability/compliance people and ask them to unsub it
en masse, if they can. Some will and it might help. We've done it before
for others.
Thank you fo
On 6/27/24 20:35, Richard Clayton via mailop wrote:
this is "list bombing" and is done to simply annoy, or more often to
hide some other message (about an unusual login, or money (or domain!)
transfer)
ACK
I didn't want to open a new thread with "bomb" in it.
some simple advice to a victim
Hi,
Is there any value in contacting postmaster@ / abuse@ for senders that
participated in a mass subscription bomb attack?
I've got a user that received almost 1k subscription / welcome /
confirmation messages over a period of about 30 minutes before I
disabled the account (hopefully tempor
On 6/5/24 11:49 AM, Graeme Fowler via mailop wrote:
As we all know, SMTP ain’t actually simple at all. Sigh.
I'll argue that SMTP is still simple.
Rather the language (protocol) that is spoken and the grammar (rules) of
how to speak SMTP are simple.
The language (protocol) is entirely sepa
On 4/22/24 09:16, Matus UHLAR - fantomas via mailop wrote:
I'm afraid this is very long term solution - the recipient needs to
trust your ARC signatures.
IMHO the "the recipient needs to trust your ARC signature" is ARC's
Achilles' heel.
I have not seen any way to get around this -- what I c
On 4/19/24 8:31 AM, Jaroslaw Rafa via mailop wrote:
I started to monitor all outgoing traffic from my server towards his
IP address with tcpdump, then I put up firewall rules that blocked
(with logging) all outgoing traffic to his IP other than to port
25. Obviously no packets were going out of
On 4/17/24 2:07 PM, Grant Taylor via mailop wrote:
Research clustered file systems and / or clustered LVM. What you find
should have SIGNIFICANT overlap with and much of it will probably be
possible in Proxmox.
Here's some additional reading that might be of interest.
TL;DR: Glowsom
On 4/16/24 23:42, Bruno Flückiger via mailop wrote:
Proxmox does not support the current architecture I have at work:
clusters of hosts served by a central storage system connected to the
hosts by FC SAN. I run few huge volumes on the storage that are shared
among the cluster hosts. As I have s
On 4/16/24 12:36 PM, L. Mark Stone via mailop wrote:
If you were really from Virginia Tech or the Max Planck Institute,
you would have used a university email address to post, instead of
a Gmail account.
I don't recognize ishtiaq ashiq, but I do recognize Tijay Chung who sent
the same message
On 4/3/24 12:55, John R Levine via mailop wrote:
Huh. Nobody tells me nothin'.
Don't feel too bad. I found out after you.
${READ_WHILE_DRINKING_MORNING_COFFEE}++
--
Grant. . . .
smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop
On 3/21/24 5:47 AM, Alessandro Vesely via mailop wrote:
Mailing lists modify messages in a de-facto standard way. It is
possible to automatically undo such changes and verify the original
signature, if it is left intact.
I feel like this is a "can vs should" type problem. There are a LOT of
On 2/26/24 10:43 AM, Jaroslaw Rafa via mailop wrote:
At least that's what I see all over from my experience.
My experience is similar.
However my opinion is that this is the wrong thing to do. Like so many
things, email is governed by checks and balances (of sorts). If enough
people compla
On 2/24/24 11:23, Anne P. Mitchell, Esq. via mailop wrote:
Not to mention that Federal law requires a one-step unsubscribe method.
My understanding is that the requirement is scoped to the 1st party
recipient of messages subject to the requirement. I bet that the same
requirement doesn't ext
On 1/26/24 16:06, Gellner, Oliver via mailop wrote:
Independent of this I wouldn’t use r...@hostname.example.org
as a sender address to external recipients. This doesn’t look
professional,
I'll agree that sending from root@ is not best practice. But
I don't know if it's unprofessional per se
On 1/25/24 01:12, Marco Moock via mailop wrote:
Both don't pass here, so fix SPF and try again.
I would hope that redacted.example.net and 192.0.2.1 fail.
redacted.example.net is part of one of the (few) names reserved for
documentation; specifically example.net. Likewise 192.0.2.1 is part o
On 1/24/24 22:12, Alexander Neilson via mailop wrote:
Was this over v6?
Nope. Hence the Test-Net-1 IPv4 address.
This was on a friends system and said friend is an IPv4 stalwart in that
he sees no benefit for the additional time and overhead for IPv6 for his
small business that has sufficie
On 1/24/24 22:09, Russell Clemings via mailop wrote:
I saw it a couple of weeks ago.
I wonder if what they meant by February 1st is that's when they would
hit the 100% requirement and they are doing the 1% / 5% / 10% / 50% /
80% / 100% ramp up now.
Similar, a server reporting in via cron.
Hi,
I knew that Google was going to start requiring SPF or DKIM (in addition
to other sender guidelines [1]. But I thought they were starting
February 1st, per their own sender guidelines.
I saw a bounce from a system (cron job output) trying to send directly
to gmail.com, no forwarding inv
On 1/23/24 1:40 PM, Michael W. Lucas via mailop wrote:
Hi folks,
Hi,
I have domains that should never receive mail. I'd like a milter that
looks for mail to those domains and feeds the IP of the sender to an
outside program.
I'm interpreting your statement to mean that you are talking abou
On 9/13/23 12:07 PM, Emanuel Schorsch via mailop wrote:
ARC trust is not just a binary. There are also ways that the ARC headers
can be used even if the ARC sealer is not 100% trusted.
Thank you for making that comment.
That helps partially elide what I consider to be a priming problem with AR
On 9/13/23 6:04 AM, Jaroslaw Rafa via mailop wrote:
If someone forwards mail to his/her account, they obviously know
*from where* they forward mail.
Aside: I originally thought you were referring to which senders would
be sending messages that would get forwarded. But after reading you
next
On 8/30/23 2:06 AM, Dan Mahoney (Gushi) via mailop wrote:
Grant, I appreciate the time it must have taken you to write this long
callout about how I surely must be "doing it wrong".
:-)
I've been running mail for 20 years now.
*nod*
I think I've been running Sendmail roughly the same amoun
On 8/23/23 4:29 AM, Dan Mahoney (Gushi) via mailop wrote:
I just posted this over on comp.mail.sendmail, but the gist of it is:
Sometimes spamhaus hands off a query to their dnsbls of 127.255.255.255
or 127.255.255.254, indicating that you're being rate limited.
With all due respect, this see
On 8/23/23 11:00 AM, Michael Grant via mailop wrote:
I've been waiting for someone to layer something like yaml on top of
sendmail's M4.
First: It's not /Sendmail/'s M4. M4 is it's own stand alone language
-- one I find quite useful -- which Sendmail happened to utilize.
Aside: Is it IBM'
On 7/14/23 9:22 PM, John Levine via mailop wrote:
Well, sure. What do you think mailing list MIME digests are?
I assume that you're referring to multipart/digest.
The disadvantage is that a lot of mail systems, particularly popular
webmail, deal poorly with embedded messages.
Agreed.
I'd
On 7/14/23 11:20 AM, Slavko via mailop wrote:
Hi,
Hi Slavko,
Possible? Yes. Expected? Hard to tell... See latter.
From which point of view?
My experience is that hard and fast usually surfaces errors much closer
to the time they are introduced.
Conversely soft and slow usually causes e
On 7/14/23 11:31 AM, Michael Peddemors via mailop wrote:
You all realize that the poor guy looking for a guide on how to set up
and email server long since left, you scared him to death with the
complexity..
Why does an active ongoing conversation between multiple parties need to
stop because
On 7/14/23 9:26 AM, Marcel Becker via mailop wrote:
Yes, of course. We wouldn't do it otherwise. It's billions. And it kept
getting worse.
Can ~> will you share any rough (as in order of magnitude / log10)
numbers? -- If so, please do.
One of the things that I find so confusing about this
On 7/13/23 10:56 AM, Slavko via mailop wrote:
Ahoj,
Hi,
OK, our opinions are near the same, but still opinions only, without
something in RFC.
:-)
IMO one cannot apply SPF independently nowadays.
I absolutely think that it's quite possible to apply SPF independently
nowadays.
Sure, y
On 7/13/23 10:49 AM, Bill Cole via mailop wrote:
It's not at all logically hard to meet that arbitrary requirement, you
just need a zone cut everywhere you have a MX record. I've run a DNS and
mail hosting environment that way. Zone files are very small and
numerous. *Logistically* changing an
On 7/13/23 4:00 AM, Hans-Martin Mosner via mailop wrote:
Has anyone on this list tried forwarding (e.g. for ex-employees) via
attachment?
I have done exactly this on a onesie-twosie / manual basis.
I have .forward files on systems that I administer and can run into
problems when I send an ema
On 7/13/23 2:24 AM, Gellner, Oliver via mailop wrote:
The requirement is actually less restrictive as it only requires a
SOA record and not additional A, or MX records in DNS. It is not
necessary that every hostname has a SOA record, that indeed would be
unreasonable. Yahoo only requires a
On 7/12/23 9:28 AM, Jaroslaw Rafa via mailop wrote:
Despite I said that SPF/DKIM/DMARC adds little to security, I would
disagree with what you write here.
The problem is for recipients, not for senders.
I'd argue that almost all SMTP shortcomings are on the receiving end,
not the sending end
On 7/12/23 4:11 AM, Slavko via mailop wrote:
BTW, my English is not best, don't take me word by word, please...
I don't think I've had any more trouble understanding you / your use of
English as an additional language than I have had with others who use
English as their primary language. Dif
On 7/12/23 1:02 AM, ml+mailop--- via mailop wrote:
Maybe you can explain how you tested it and which software (MTA?)
was used?
Sure.
I stood up a VPS and configured Sendmail as I have done for 20+ years.
I created a (sub)domain-name -- in a different domain than my main
domain name -- that r
On 7/11/23 4:20 PM, Jaroslaw Rafa via mailop wrote:
For start, I suggest to implement SPF, DKIM and DMARC only for
outgoing mail, and in fact only to satisfy Google's requirement that
these should be in place. Don't bother checking them on incoming
mail. (It's actually how I do it).
I am extrem
On 7/11/23 4:31 PM, Jaroslaw Rafa via mailop wrote:
Hm... does this smell a bit X.400 or is it only my impression?
I believe the idea is protocol agnostic.
But I used to see it more in the '90s back when X.400 / OSI was much
more of a thing.
I am quite certain that I've seen this type of B2
On 7/11/23 3:00 PM, Jarland Donnell via mailop wrote:
Does anyone actually receive mail by their A record in 2023? I'd just
assume break the RFC and save the resources for retrying and eventually
bouncing every email that ends up attempting delivery to an A record.
I have seen a-record fallbac
On 7/11/23 2:48 PM, John Levine via mailop wrote:
If your From: domain has neither an A nor an MX, I don't think
you're going to get much mail of any sort delivered.
I believe it's possible for two entities to configure their email
servers to exchange email with each other without the use of DNS
On 7/11/23 2:45 PM, Michael Orlitzky via mailop wrote:
5.1. Locating the Target Host
Thank you for the pointer Michael.
Today I Learned :-)
Grant. . . .
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 7/11/23 2:09 PM, Sebastian Nielsen via mailop wrote:
I think sender adress should be changed.
I think that /forwarding/, as in altering the envelope recipient
address(es), probably should have the envelope sender address changed.
I say /probably/ because I'm sure there are some situations
On 7/11/23 10:08 AM, Benny Pedersen via mailop wrote:
on next hub envelope sender changes, so new spf problem when next hub
forwards mails
This behavior is not guaranteed and SHOULD NOT be relied on. If it
works, then great! But don't be surprised if it doesn't work.
I remember Sender Rewr
On 7/11/23 12:35 PM, Michael Orlitzky via mailop wrote:
Seriously though, it's not a "fallback" in any pejorative sense.
SMTP predates much of DNS, including MX records. It's a fundamental
part of the specification.
I largely agree, especially from a historic point of view.
However, I don't s
On 7/11/23 8:29 AM, Bill Cole via mailop wrote:
It is worthwhile to protect the details of a SMTP session on the wire,
beyond simply protecting the contents of email.
Agreed.
+1
E2E tend to only address data and completely ignores metadata which
transport encryption helps.
Grant. . . .
_
On 7/11/23 4:54 AM, Slavko via mailop wrote:
If something have to be said, then it have to be said and then
doesn't matter who said it ;-)
Well said.
Nowaydays (especially joung) people tends to feel as experts, when
they setup something first time. Thus, when not used word by word, it
is goo
On 7/11/23 8:15 AM, Bill Cole via mailop wrote:
Surprisingly, A-record fallback works just fine for B2B email.
My experience differs. I've found A-record fallback to work inconsistently.
I think that A-record fallback is dependent on the sending MTA.
No one notices. Or at least no one appear
On 7/11/23 4:26 AM, Jaroslaw Rafa via mailop wrote:
TECHNICALLY, any email (there is no technical difference if it is B2B
or not) requires only a machine that has an A record and a running
MTA.
I'll wager a lunch that A records aren't even required. Maybe not any
name resolution at all. Thi
On 7/11/23 4:18 AM, Jaroslaw Rafa via mailop wrote:
Sadly, you're probably right. It would take someone as universally
trusted (and as trustworthy) as Jon Postel was once, to run such a
service. But there are no people like Jon Postel in decisive
positions anymore...
Yes, I try to find the goo
On 7/10/23 2:40 PM, Jarland Donnell via mailop wrote:
The problem is, running any blacklist and wanting to constantly speak to
people who are often just confused about how relevant your list even is,
are very often two different things. So there's not anyone to talk to,
at least not from a publ
Dear ${FELLOW_EMAIL_ADMINIATRATOR},
I don't know how to preface this email other than to say -- I believe
the following needs to be said lest we loose even more control of our
email community.
I'm sorry that both 1) I feel that the following needs to be said and 2)
that I'm the one that's sa
On 6/28/23 11:07 AM, Chris Truitt via mailop wrote:
The Mimecast spam checking appears to be clicking every link. This has
inadvertently caused an uptick in Unsubscribes.
Aside: Isn't this why the unsubscribe links are encouraged to use /
require a POST so that simple GETs don't accidentally
On 3/28/23 12:49 PM, Mike Hillyer via mailop wrote:
In the spirit of splitting hairs, as someone who has opened a retail
business, code violations are usually something that *hasn't* been
done. In this case updating a server.
Eh ... a choice, possibly unconscious, was made to not do what was r
On 3/28/23 11:37 AM, Mike Hillyer via mailop wrote:
But the fire marshal can shut down a business before it burns to the
ground for code violations.
The operative phrase is "for code violations".
As in something has been done.
I'm not aware of any widely recognized code that says that your SM
On 3/28/23 11:07 AM, Al Iverson via mailop wrote:
You're sort of trying to argue me out of agreeing with you. Here's
the parallels I see.
?
A Sendmail server so old that it can only be an open relay. Block
it proactively? Or block it only after it has been exploited?
1st, I said /contempora
On 3/28/23 10:19 AM, Al Iverson via mailop wrote:
Eventually we have to stop allowing connections from misconfigured
servers that are being exploited to do bad things.
But what is "misconfigured"? How do you define that from a technical
level? How do you identify that?
I agree that "server
On 3/26/23 2:32 PM, Jaroslaw Rafa via mailop wrote:
One big downside: you need to have two MXes.
I don't view multiple MX records as a bad thing.
Or are you referring to IPs that two different names resolve to? --
There are multiple ways around this.
I don't understand ~> appreciate the pr
On 3/25/23 3:10 PM, Heiko Schlittermann via mailop wrote:
We used MX sandwiching/NoListing on our own MXs and had issues sending
messages to remote sites which did sender verification via a poorly
implemented callback.
So, is it fair to say, that you had problems sending to site that used a
q
On 3/25/23 2:25 AM, Heiko Schlittermann via mailop wrote:
Ah, ok, that's what I know as MX sandwiching.
Interesting. I'll have to research that phrasing to see if I can learn
more about it.
Ok, that was your point. Sure. We tried this (NoListing, MX
sandwiching) for a while and had problem
On 3/24/23 4:01 PM, Heiko Schlittermann via mailop wrote:
Hm. Maybe I'm stupid.
Nope. I'm sure that's not the case. We all learn things when exposed
to new things. ;-)
What does this change? From senders PoV it is a temporary error. The
sender will retry.
NoListing works by causing the
On 3/24/23 1:24 AM, Renaud Allard via mailop wrote:
I would say, that's called greylisting. But with a changing envelope,
the message has no chances to pass any greylisting process. The
behaviour from mailgun would make them unable to pass any kind of
greylisting anywhere.
That's one of the a
On 3/9/23 12:45 PM, Michael Peddemors via mailop wrote:
Okay, better expand on what I am saying.. say you have a bunch of IPs
from Linode, .. you 'might' want to indicate better what they are for..
eg..
sharedhosting.hisdomain.com
mailout.hisdomain.com
etc..
If the PTR's still reflect the ge
On 3/9/23 2:03 PM, Gellner, Oliver via mailop wrote:
Also some MTA may use different or stricter checks for IPv6 than for
IPv4, so it‘s possible that a message gets rejected while it would have
been accepted if delivered via IPv4.
I believe Google has more stringent requirements for IPv6 than
On 3/9/23 10:45 AM, Michael Grant via mailop wrote:
If I can get this spamhaus issue solved, why should I not just leave
it in place so my mailer will talk ipv4 or ipv6? Why just stick
with ipv4? I realize it's not necessary today to be able to send on
ipv6 but why should I not get this worki
On 3/9/23 9:45 AM, Michael Peddemors via mailop wrote:
Yes, it's called 'rwhois'. Of course, linode can SWIP the larger
portions, with a clear indication of what parts of the IP space are used
for what.
I've opened multiple support tickets with Linode over the years asking
for SWIP and / or
On 3/2/23 12:27 PM, Tobias Fiebig via mailop wrote:
The tool looks for a perfect world, which there isn't. ...
Still, if i'd not deduct points for those things, everyone would get
a 10. ;-)
I have no idea if your infrastructure / UI could support this or not,
but what if you had an option to
On 2/28/23 2:51 PM, John Levine via mailop wrote:
It's not common and I would be astonished if anyone checked as part
of delivery.
I wouldn't mind if the test called it out mostly in the sense that:
- I would want case consistency
- I'd be worried about tickling a bug in someone else's softwa
On 2/16/23 1:47 PM, Benny Pedersen via mailop wrote:
please dont suggest this
I agree that these ... questionable ... solutions are sub-optimal.
However I fully agree that each email server operator is free to run
their own email server as they see fit (or allowed to do by management).
I th
On 2/9/23 2:21 AM, Gellner, Oliver via mailop wrote:
In my experience the spam report button is not only used as a sort
of fast unsubscribe, but also as a replacement for the delete button.
Knowing how unreliable training the end user is, I wonder if it's worth
altering the equation wherein we
On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote:
Why?
Another primary use case I have is a company owner moved a system from
the office to their house as they moved states and the new ISP filters
destination TCP port 25. So having something in the mail wrapper being
able to communicate d
On 1/11/23 3:39 AM, Jaroslaw Rafa via mailop wrote:
Why?
Your script will run as a part of existing mail flow anyway, within
an existing MTA. Making use of this existing MTA seems to be the
logical choice, instead of trying to replicate its function yourself.
Consider a scenario where the lo
On 1/10/23 2:59 PM, Dan Mahoney via mailop wrote:
Sometimes a problem comes across your desk that you say “wait,
how is this not solved yet?”.
Ya
I too have wanted something like this to enhance ~/.forward files on
servers that I manage, while addressing all the problems that you're
desc
On 12/19/22 8:21 AM, Daniele Nicolodi via mailop wrote:
it seems that Nextdoor recently went on a mission to expand their user
base and are mailing former users with whatever crap.
I assume that their excuse for why the contact is CAN-SPAM compliant is
because of the "established business rela
On 12/7/22 6:46 AM, Matt Vernhout via mailop wrote:
CAN-SPAM, CASL and several other Anti-Spam/Digital Marketing laws
require that the recipient only need to supply their email addresses to
unsubscribe. It may also be a requirement of their ESP, send a note to
the abuse desk for 1 unsolicited e
On 11/23/22 8:38 AM, Slavko via mailop wrote:
Anyway, using SPF on shared environment is something, what negates SPF
purpose at all, as anyone from that shared provider can succesfuly pass
SPF for any other domain in it (sharing the same TXT records). Thus in
these shared services is SPF mostl
On 11/2/22 3:26 AM, Alessandro Vesely via mailop wrote:
By comparison, DNSWL.org seems to be more widespread, as it is often
queried by commonly used tools like SpamAssassin and Rspamd.
Registration is automated and free[†].
I agree that DNSWL is also a good resource.
However, I also believe
On 10/31/22 11:39 AM, Andrew C Aitchison via mailop wrote:
If it is useful isn't three bucks small enough for the spammers
to pay too ?
My understanding is that spammers are trying to be as cheap as possible.
Considering that the price per listing of each IP is 60% of the price of
the smalles
On 10/30/22 5:35 PM, Ian Evans via mailop wrote:
DO admits their IP reputation sucks and so won't intervene with
vadesecure on behalf of my IP.
I'm surprised and disappointed that Digital Ocean won't do anything to
vouch for "yes, this customer is using this IP, and has been for $TIME".
I'm
On 10/24/22 12:01 PM, Tara Natanson via mailop wrote:
The forward is set up to send out our postmaster@ address, So I can't
let it bounce. :(
I can respect that.
I wonder if it would be possible to implement a conditional rejection
that matches details of the problematic message.
I would a
On 10/22/22 12:55 PM, Sebastian Nielsen via mailop wrote:
Think the "imprint" as a hygiene certification for a public for-pay
internet service. Think like a digital restaurant, and you understand
why these laws are there.
I'm not so sure about that.
I thought the imprint was simply official c
On 10/22/22 12:31 PM, Slavko via mailop wrote:
As fan & contributor to open source software i do not agree, no,
not all is about money only.
I am particularly impressed with the FCC's use of "no pecuniary
interest" when discussing operating on an amateur radio license.
My understanding is "p
On 10/22/22 9:00 AM, Sebastian Nielsen via mailop wrote:
If you provide free services, customer can't expect anything, and
you are free to do as your wish. If your email service goes down,
so what? Customer got it for free, not our problem. If you win a
toaster in a free competition that requi
On 10/21/22 1:02 PM, Jaroslaw Rafa via mailop wrote:
As many have pointed out, putting this information online may be
harmful to privacy and even facilitate criminal acts against you.
I still feel like there is room for an abstraction layer wherein you
provide a postal address and telephone nu
On 10/21/22 10:30 AM, Laura Atkins via mailop wrote:
I know a number of mailservers that are able to successfully send mail
to t-online.de and have never contacted the tosa@ address.
I wonder if that hints at a thus-far un-discussed aspect of T-Online's
policy.
There is every chance that T-O
On 10/20/22 9:53 PM, Jyri J. Virkki via mailop wrote:
None of the three analogies is really comparable (phone call, postal
mail, taxi) because in each case the person doing the rejecting is the
intended recipient. Who certainly has the moral right to reject.
All three scenarios can be extended
On 10/20/22 9:14 PM, Kai 'wusel' Siering via mailop wrote:
But their "policy" does not adhere
Yes, T-Online /does/ adhere to T-Online's policy of only accepting email
from senders that T-Online considers to be blessed.
No. They 554 anyone, including me from any of my 1k+ v4 IPs except for 2
On 10/20/22 4:49 PM, Kai 'wusel' Siering via mailop wrote:
Another rule from an earlier era outlines one of the fundamental
principles of the Internet Agreement: I will accept your traffic,
*subject* *to* /my/ *policies* and agreements, if you will accept mine,
*subject* *to* /your/ *policies*
On 10/20/22 1:22 PM, Kai 'wusel' Siering via mailop wrote:
Well, it's both at the SMTP layer:
Same level.
You are obviously as free to run your server(s) as you want as T-Online
is to run their servers as they want.
I don't get your point, as that is what t-online.de is effectively doing.
On 10/20/22 10:32 AM, Jaroslaw Rafa via mailop wrote:
I consider this being purely a connectivity thing.
Except that it's not a /connectivity/ thing. At least not on any OSI
layer. The rejection that you are advocating for is sent across / over
/ through the established connection. So, no,
On 10/20/22 9:17 AM, Jaroslaw Rafa via mailop wrote:
+1
Could you please repost this to appropriate Exim and Postfix mailing lists?
-1
I believe providing a config which is enabled by default that rejects
email from a provider is a disservice to the industry at large and will
only promote f
On 10/20/22 7:51 AM, Kai 'wusel' Siering via mailop wrote:
Well, just use your ISP's submission service, problem solved. Or pay
someone to MX you domain, problem solved.
I don't agree that the problem is /solved/. Rather I think using such
an external problem /changes/ or /moves/ the problem
On 10/19/22 9:01 AM, Benny Pedersen via mailop wrote:
imho same problem as i reported here
https://gitlab.com/fumail/fuglu/-/issues/262
There may be a legitimate bug in the DKIM implementation /if/ it's
signing things without the knowledge of the operator.
That being said, over-signing is a
On 10/19/22 7:25 AM, Johann Haarhoff via mailop wrote:
T-Online:
the IP address is delegated to your provider and there
is no owner data in the public whois record for your domain.
Thus, the person or company who is responsible for this host is
essentially anonymous to third parties.
Theref
On 10/18/22 8:28 AM, WIlliam Fisher via mailop wrote:
I'm pretty sure DKIM wouldn't include the non-standard threading
headers.
/Default/ DKIM configurations probably don't include the threading
header(s) (References & In-Reply-To). But it's certainly possible that
they are included.
That
On 10/17/22 10:17 PM, Brandon Long via mailop wrote:
Right, but you can't stick a non-compliant message into a DSN
directly and have that be a compliant message... so you either make
the non-compliant message compliant when you stick it into the DSN,
or you figure that a sender who sends a non-
On 10/17/22 9:11 PM, Brandon Long via mailop wrote:
Certainly, but do you consider some edge cases like composing bounces
or relaying messages as generating messages?
Yes, generating a DSN is generation of a message. No, /relaying/ is not
generating a message.
I'm using "did the outgoing me
On 10/17/22 8:35 PM, Brandon Long via mailop wrote:
The line length limit was clearly designed for a different time in
terms of memory usage, and I think a lot of mail software has much
larger workarounds for specific client/server bugs... I'd just raise
the limit.
I'd be okay with raising t
On 10/17/22 4:02 PM, Heiko Schlittermann via mailop wrote:
Hi,
Hi,
how do you deal whith incoming messages having a Thread-Index header
... with about 1200 chars.
I can't say as I've had the (dis)pleasure of dealing with such.
I would (try to) configure my MTA to re-wrap the logical line t
On 10/14/22 10:41 AM, ml+mailop--- via mailop wrote:
Almost no MTA cares about the certificate content unless explicitly
configured to do so.
Emphasis on MTA.
I've witnessed Thunderbird, and heard tell of other /MUAs/, caring about
the CertSubject and AltNames matching the name used to connec
1 - 100 of 311 matches
Mail list logo
