On Wed, Sep 04, 2024, Viktor Dukhovni via mailop wrote:
> However, when milters are in use, the per-logical header limit is
> silently capped at 6 bytes in aid of compatibility with the milter
> API, where client requests must not exceed 64KB. The total header
_FFR_MDS_NEGOTIATE is available
On Wed, Aug 28, 2024, Robert Giles via mailop wrote:
> On 8/28/2024 at 08:08, Gellner, Oliver via mailop wrote:
> > You can use the header X-Google-Group-Id.
> Thanks! That looks like an excellent header to use for a Postfix REJECT
> action.
Be aware that some "important" mailing lists switched
On Fri, Jul 12, 2024, Jesse Hathaway via mailop wrote:
> I am a little wary of standing it up, given the lack of maintained open
> source milters.
If a program just works, why should it be updated?
--
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws u
On Fri, May 17, 2024, Cyril - ImprovMX via mailop wrote:
> So, I wonder, is there another RFC that specifies a bigger line length,
No.
> or are the RFC here just for decoration?
"We don't care. We don't have to. We are the phone company".
Of course you could argue to "be nice and accept invali
On Thu, Mar 14, 2024, Marco Moock via mailop wrote:
> Am 14.03.2024 schrieb Julian Bradfield via mailop :
> > On 2024-03-14, Marco Moock via mailop wrote:
> > > sendmail tried to deliver it 20 times during the night - this
> > > morning I deleted the mail from mqueue.
> That is the default in
On Wed, Mar 13, 2024, Harald Hannelius via mailop wrote:
> Are there SMTP-"clients" that actually are able to back down from STARTTLS
> and continue unencrypted?
Very unlikely. If the TLS handshake fails, a server usually drops
the session because it is in an unknown state.
What several clients
On Tue, Feb 27, 2024, Matt Palmer via mailop wrote:
> > 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [nagler.me] with ip:
> Any chance of a transient/intermittent DNS failure on nagler.me? On
That should not result in a permanent (550) error but
just cause a temporary (4xy) error.
--
P
On Sat, Jan 13, 2024, Sebastian Nielsen via mailop wrote:
> Why is it a problem? The server ignores commands that it don't have
> capability for anyways.
Says who?
555 MAIL FROM/RCPT TO parameters not recognized or not implemented
--
Please don't Cc: me, use only the list for replies, ev
On Mon, Jan 01, 2024, John Covici via mailop wrote:
> I use sendmail 8.17.1.9 under gentoo -- any patch for that one to fix this?
Upgrade to 8.18.0.2,:
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz.sig
_
On Tue, Dec 19, 2023, Slavko via mailop wrote:
> Please, understand i properly, that it is no vulnerabiliy in SMTP itself,
> but in (some) implementations/servers only?
The RFC is very precise about line endings and "end of message".
Some (legacy) MTAs try to be "nice" and accept other line endin
On Mon, Dec 18, 2023, Paul Smith* via mailop wrote:
> DKIM (and SPF) aren't anti-spam measures, and have never been promoted as
> such. They're anti-forgery measures.
I know that -- which is why I don't use either (besides other reasons,
e.g., breaking existing mail mechanisms).
> spammers can p
On Mon, Dec 18, 2023, Gellner, Oliver via mailop wrote:
> On 17.12.2023 at 21:48 Michael Peddemors via mailop wrote:
> > A bit off topic, but it is always amazing.. rejecting based on no DKIM?
> > It's like most new requirements, ever notice that the spammers are
> > implementing these requireme
On Sat, Dec 16, 2023, Thomas Walter via mailop wrote:
> I still think Microsoft should not complain about NDRs, especially if the
> original was from them.
That's probably just the normal case of filtering mail when it is
coming in, but not when it is going out (that's what those companies
do, ri
On Sat, Dec 16, 2023, Thomas Walter via mailop wrote:
> 2. Our server bounces with 550 5.1.1 User doesn't exist.
Does your server generate a DSN?
If the "User doesn't exist" then it seems you should be able to
determine that fact when RCPT is given -- or is this just a bogus
reply?
--
Please do
On Fri, Oct 27, 2023, Marco M. via mailop wrote:
> Am 27.10.2023 um 15:19:33 Uhr schrieb Cyril - ImprovMX via mailop:
> > For instance, if my server has a PTR with mail1.example.com, and I
> > connect by saying "HELO send.example.com". If the receiving server
> > loads all the IPs for "send.exampl
On Mon, Sep 11, 2023, Camille - Clean Mailbox via mailop wrote:
> 2023-09-11T22:47:26.496119+02:00 mx1 postfix/smtpd[850937]: warning: TLS
> library problem: error:0AC1:SSL routines::no shared
> cipher:../ssl/statem/statem_srvr.c:2220:
Did you change the default TLS settings (of postfix), e.g
On Wed, Aug 30, 2023, Dan Mahoney (Gushi) via mailop wrote:
> I've also discovered (over on comp.mail.sendmail) that SpamHaus's
> recommended, documented use of the enhdnsbl feature DOES NOT WORK, which I
You should have read the fine (sendmail) documentation instead:
FEATURE(`enhdnsbl', `dnsbl.
On Wed, Aug 23, 2023, Dan Mahoney (Gushi) via mailop wrote:
> It looks like the version of enhdnsbl.m4 simply checks for *any* return code
Have you checked the fine documentation?
cf/README:
enhdnsblEnhanced version of dnsbl (see above). Further arguments
(up to 5) can
On Wed, Jul 12, 2023, Andrew C Aitchison via mailop wrote:
> Please could you indicate who you are and,
Why?
> if appropriate, who you work for or represent ?
I do not represent anyone but myself. Hence I prefer not to give
out my name because then some people might think that I speak for
"some
On Wed, Jul 12, 2023, Grant Taylor via mailop wrote:
> with Sendmail) send a test message to my user at the test domain. That
> didn't work. I think that Sendmail in the MSA role rejected things out of
Sorry, but "didn't work" is a completely useless problem description.
Provide real data and re
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:
> I have seen a-record fallback work, as in legitimate email flow, for others
> within the last two years.
> I have not been able to get it to work in my testing.
Maybe you can explain how you tested it and which software (MTA?)
was used?
--
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:
> However, I don't see any mention of a-record fallback in RFC 5321. -- I
> didn't chase any updates. -- I do see four occurances of "fall" in the
Maybe you should have looked for "MX" instead of "fall"?
... If
no MX records are fou
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:
> I think that A-record fallback is dependent on the sending MTA.
And which MTA are those which do not implement the RFCs properly?
"We are ..., we don't care about standards"
> Though if memory serves that's because my MTA of choice balks at
On Sun, Jun 25, 2023, Carsten Schiefner via mailop wrote:
> The question, however, is: will it ble..., erm, can one do without
> greylisting?
It would mean more spam is coming through - so for my case greylisting
is not useless -- which was the unsubstantiated claim to which I
replied.
--
Pleas
On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:
> What if we just got to the heart of the matter and admitted that
> greylisting is useless 2023?
It isn't.
(it works fairly well for the way I'm using it...)
--
Please don't Cc: me, use only the list for replies, even if the
mailing list softw
On Mon, Apr 03, 2023, Jay Hennigan via mailop wrote:
> Final-Recipient: rfc822; ab...@asalesforce.com
Does that mean ab...@salesforce.com is redirected to
ab...@asalesforce.com ?
--
Please don't Cc: me, use only the list for replies.
___
mailop mailin
On Tue, Feb 28, 2023, Andrew C Aitchison via mailop wrote:
> Is there an SMTP equivalent of the HTTP 30x status codes ?
Maybe this: RFC 5321:
551 User not local; please try (See Section 3.4)
--
Please don't Cc: me, use only the list for replies.
On Sun, Dec 25, 2022, Peter Nicolai Mathias Hansteen via mailop wrote:
> but since they have no valid MX record
What's wrong with the MX records?
dig antispamcloud.com. mx
antispamcloud.com. 600 IN MX 10 filter10.antispamcloud.com.
antispamcloud.com. 600 IN MX
On Sun, Nov 27, 2022, Hans-Martin Mosner via mailop wrote:
> > IMHO it would be nice if those (misleading) "tags" could be removed
> > before replying,
sorry if I wasn't clear: I meant removed by the person who is
replying, not by some software.
> Of course he could have removed that
> tag by h
Hmm, so something "tagged" the previous mail as
[Marketing Email]
Subject: Re: [mailop] [Marketing Email] t-online.de
Seems to be really bogus to me
IMHO it would be nice if those (misleading) "tags" could be removed
before replying, similar to "[External]", "[Probably Spam]", etc,
esp. if
On Nov 21, 2022, at 18:29, John Levine via mailop wrote:
> I understand why that's the conventional wisdom, but I also don't
> understand why, if all the resources are on the same LAN as the name
> servers, the conventional wisdom would apply.
This doesn't apply to postfix.org -- the mailing lis
On Thu, Oct 27, 2022, Otto J. Makela via mailop wrote:
> Unfortunately sendmail doesn't seem to have anything to do this on
> a permanent basis (ref: Claus AÃmann on comp.mail.sendmail), I'd be
> fine with IPv4 outgoing IPv4/IPv6 incoming.
A patch has been posted to comp.mail.sendmail,
but seemi
On Sat, Oct 29, 2022, Benny Pedersen via mailop wrote:
> https://multirbl.valli.org/fcrdns-test/2a01%3A111%3Af400%3A7d00%3A%3A33.html
> such clients will not deliver email here, as the t-online.de dont accept
It seems those were supposed to be servers. Do you have
any evidence that they were use
On Thu, Oct 27, 2022, Peter Beckman via mailop wrote:
> Deferred: 451 4.7.500 Server busy. Please try again later from
> [2a01:111:e400:7e0d::51]. (AS750)
Doesn't the MTA (which one do you use?) also try IPv4
or were there no A records at all?
Do you still have the results for the MX
"What's the problem you are trying to solve?"
Almost no MTA cares about the certificate content unless explicitly
configured to do so. Some check the names (CertSubject or AltNames),
and some are "misconfigured" to require a cert signed by some
specific CAs.
Testing with just one or two other sys
My system is getting spammed by outbound.protection.outlook.com
mail=
rcpt=, stat=550
rcpt=, stat=550
and this happens again and again.
(note: it happened before with other MAIL addresses)
It their MTA broken -- ignoring 550 for RCPT?
Or is the sender submitting the mail again and again?
the lat
On Sat, Sep 03, 2022, Carl Byington via mailop wrote:
> A former client was trying to setup Fedora 36 sendmail with dane
> validation. F36 comes with sendmail 8.17.1 which is supposed to support
> dane, but they get verify=fail talking to my mail servers. So I googled
If would have been nice if y
How did you notice that "something is now broken"?
"works for me" - I just tried it with an MTA that supports DANE:
server=172.102.240.42,
starttls=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, verify=DANE_SEC,
cert_subject=/CN=mail3.five-ten-sg.com,
cert_issuer=/C=US/O=Let's+20Encrypt/CN=R3,
pubkey_fp
> _25._tcp.mail3.five-ten-sg.com. IN TLSA 3 0 1 (
> 834d710b2feb790cc9b2c6d251c65b1fedc24c51a4149bdfeae4d40e0be11892
Are you sure you want 3 0 1 and not 3 1 1?
Isn't the second number the selector:
0 -- Full certificate: the Certificate binary structure as defined in [RFC5280]
1 -- SubjectPubli
On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:
> Sorry, thought it was clear, they are using bare line feeds on their
> injected headers..
Hmm, I've seen that bug before in some software at $WORK :-(
They didn't even notice it until some DKIM verifier finally failed
due to that bug.
__
On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:
> The reason we are seeing this behavior for 2 antivirus: Both AVG and
Can you share which "bad modifications" are made?
--
Address is valid for this mailing list only, please do not reply
to it directly, but to the list.
___
My system is getting spammed by outbound.protection.outlook.com
First they are sending every 10 minutes to the same two unknown
addresses until I blocked the sender (@emss.gov.eg) then it stopped.
Now they are sending to the same addresses using
lr...@incm.gov.uk
as sender -- AFAICT the domain do
Can you give an example which shows this behaviour?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On Fri, Jul 15, 2022, Michael Ellis via mailop wrote:
> C:\Users\philipt>nslookup -q=mx csc-emarketing.trimaxdirect.com
The MX record has nothing to do with this simple check.
> 7/13/2022 11:12:35 AM Mail server: 550-5.7.25 [173.160.100.85] The IP
> address sending this message does not have a
On Fri, Jul 15, 2022, Michael Ellis via mailop wrote:
> Am I missing something as well? Google just rejected a client due to
> PTR on mailop-boun...@mailop.org but it seems fine to me
What is "PTR on mailop-boun...@mailop.org"?
Can you post the rejection and the relevant logs?
___
On Wed, Jul 13, 2022, Philip Paeps via mailop wrote:
> As far as I can tell, the message is compliant. It doesn't have any of the
Can you post it so others can check?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On Mon, Jun 20, 2022, Grant Taylor via mailop wrote:
> When was the last time that anyone has seen the fall back to A record work?
Which broken software has this bug? (an obvious RFC violation --
an "MTA" of one of those companies who don't care about RFCs anyway?)
It works fine in the MTAs tha
On Thu, Jun 09, 2022, Johann Klasek via mailop wrote:
> The whole line may look like this:
> sendmail[12403]: 259I6JFw012399: to=, delay=00:00:01,
> xdelay=00:00:01, mailer=esmtp, pri=139340, relay=gmail-smtp-in.l.google.com.
> [IPv6:2a00:1450:400c:c00::1b], dsn=5.0.0, stat=Service unavailable
On Tue, Apr 05, 2022, Paul Vixie via mailop wrote:
> google e-mail addresses were signing up en masse for mailman lists here, and
> the resulting confirmation e-mail from mailman was seen by google as spam.
> i've since turned off confirmation e-mail, and i've added SPF checking to
"confirmation
On Thu, Mar 03, 2022, Bill Cole via mailop wrote:
> Did I miss something?
Maybe... I provided examples before.
> I have no idea what GMail is rejecting in SMTP
See Message-ID: <20220302163128.ga95...@veps.esmtp.org>
I have no idea why GMail rejected those mails at the final dot.
> and no one
On Thu, Mar 03, 2022, Bill Cole via mailop wrote:
> Interestingly, none of my GMail accounts has ever had ham misclassified as
> spam.
Again: how do you know whether you didn't even receive a "ham"
e-mail because it was "misclassified as spam" and rejected during
the SMTP dialogue? Do you get a l
On Wed, Mar 02, 2022, Graeme Fowler via mailop wrote:
> Whilst I may occasionally - like 5 or 6 times a year - have something that
> lands in the Junk folder, I almost _never_ receive âobviousâ spam in the
> Inbox, and neither do they.
How do you know you are not missing (important) mail?
On Thu, Feb 10, 2022, Bill Cole via mailop wrote:
> Yes, Microsoft has a chronic endemic problem of broken reverse DNS,
> in both IPv4 and IPv6. It cannot be relied upon.
So does Google reject mail from those misconfigured Microsoft systems?
--
Please don't Cc: me, use only the list for replies
On Sun, Dec 05, 2021, Slavko via mailop wrote:
> I think a little about it, but i cannot find other way than do not use
> To: header at all, which will be penalized in my anti-spam SW latter.
"What's the problem you are trying to solve?"
Is this about the differences between envelope and header(s
On Sun, Dec 05, 2021, Slavko via mailop wrote:
> But, please, what about header:
> To: postmaster
> ... rejected after DATA: header syntax: unqualified address not
> permitted: failing address in "To:" header is: postmaster
The syntax for envelope addresses and header addresses is "a
On Sun, Dec 05, 2021, Alessandro Vesely via mailop wrote:
> 220 resimta-h1p-037571.sys.comcast.net resimta-h1p-037571.sys.comcast.net
> ESMTP server ready
> rcpt to:
> 550 5.1.1 Not our customer
RFC 5321 SMTP October 2008
o The reserved mailbox
I am not criticizing qmail for this behaviour. If you need another
example:
The Postfix smtp(8) client normally does not wait for the server's
reply to the QUIT command, and it never waits for the TCP final
handshake to complete.
So now you have two people, who know that they are doing, having
im
On Wed, Nov 24, 2021, Michael Peddemors via mailop wrote:
> And then it terminates the connection, SSL collapses, without waiting for
> the remote mail server to acknowledge the QUIT.
Just like qmail?
Maybe it's time to change the RFC?
___
mailop maili
On Sat, Jul 03, 2021, John Levine via mailop wrote:
> >Mail from this host was rejected by a strict check:
> >citaprevia.maspalomas.com. 300 IN MX 10 82.98.157.67.
> To ask a fairly obvious question, since they clearly don't care whether they
> ever get
> any mail, why would anyo
Mail from this host was rejected by a strict check:
citaprevia.maspalomas.com. 300 IN MX 10 82.98.157.67.
I sent mail to
postmas...@citaprevia.maspalomas.com
postmas...@maspalomas.com
dnsad...@tsai.es
the latter due to:
maspalomas.com. 300 IN SOA nsjc8hos10.telefoni
On Tue, Apr 06, 2021, Michael Grimm via mailop wrote:
> Will you at t-online.de accept DANE/TSLA as an alternative?
How does DANE/TLSA help the recipient (server) to "verify" the
sending host?
> Or do I need to add DKIM signing in addition?
coming next:
"you must include a copy of your passport
On Fri, Jan 22, 2021, Patrick Ben Koetter via mailop wrote:
> The only reference to PRDR I could find, is an expired RFC draft. Is that what
> you are referring to?
Yes. Something like this:
Eric A. Hall. Smtp service extension for per-recipient data responses
(prdr). Draft, Internet Engi
On Fri, Jan 22, 2021, Benot Panizzon via mailop wrote:
> Now Assume two recipients with different Anti-Spam Settings:
...
That's what PRDR is for, but it isn't supported by many MTAs
or setups :-(
___
mailop mailing list
mailop@mailop.org
https://list.m
On 17.12.20 23:07, Mark Fletcher via mailop wrote:
> If this is really an issue, why don't we have backup A records as well?
> My website is just as important as my MXes, yet I do just fine without A
> record priorities...
This is somewhat off-topic here, but I guess you would use multiple
A recor
On Wed, Sep 30, 2020, Tim Bray via mailop wrote:
> Should it be using TLS for outbound connections??? I'm not seeing that?
Received: from mx.mailop.org (mx.mailop.org. [91.132.147.157])
by ... with ESMTPS
(TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK)
> Receive
On Mon, Aug 31, 2020, Mark E. Jeftovic via mailop wrote:
> So the list archives are still down then?
I tried to contact owner- about it but got a bounce,
while request- was at least delivered.
> I was hoping to link to a thread.
I was looking for that too and found
https://www.mail-archive.com/
On Wed, Aug 26, 2020, Michael Peddemors via mailop wrote:
> There SHOULD be a URL associated with the domain ('mydomain.com') in the PTR..
Ah, the stuff you suggested on ietf-smtp and which got "rejected" by
pretty one every one who replied?
___
mailop
> But it was enough to have the imprint visible for them just for the
Sorry for a stupid question: What is "the imprint"?
Does that mean you have to operate a web server with an "Impressum"
(I guess that's the German word?) if you want to send mail?
___
On Sun, May 17, 2020, Alessio Cecchi via mailop wrote:
> the domain name is stefanoboschi.it and after the transfer from one
dig stefanoboschi.it. mx
stefanoboschi.it. 3500IN MX 10 mx01.cbsolt.net.
stefanoboschi.it. 3500IN MX 20 mx02.cbsolt.net.
connecting
Talking about RDNS issues:
Since Saturday bankofamerica.com seems to have a problem with their
DNS too -- I tried to contact them directly but (so far) nothing
happened.
Their "alerts" are sent by hosts with IPs like
68.232.194.1 - 68.232.194.14 (exacttarget?)
which map to mta*.ealerts.bankofamer
On Mon, Feb 17, 2020, ngel via mailop wrote:
> I contacted them in order to warn them about the issue. They are not
> aware of any email issue and asked for the destination mailbox that had
> problems.
I was given the e-mail address
correosduap...@correos.es
from a local post office and it worked
I hope this is the right place to ask questions like this. I've
been in contact with correos.es for a while about a problem with a
package the is on the way to me.
But for about two weeks now their mailserver is no longer reachable
from my hosts (I tried 3 different hosts in 3 different countries)
Usually I don't reply to top-posted mails...
1. Try with
openssl s_client -connect other.host:25 -state -debug -crlf -starttls smtp ...
and add parameters to match your sendmail setup.
2. See cf/README how to set the option in your mc file:
confCIPHER_LIST CipherList [undefined] Ciph
On Thu, Jan 23, 2020, John Covici via mailop wrote:
> Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect
> failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1
AFAICT it's the key from "the other side" that openssl is complaining
about -- did you recently upgrade
I don't read HTML mail unless absolutely necessary (i.e., I "need"
the information that the mail contains); I don't want to trigger
all the tracking stuff in the HTML part.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mai
> MAIL FROM: @marketplace.amazon.in
A strict syntax check would reject this
:-)
(e.g., no space after : allowed)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
On Sun, Nov 24, 2019, Michael Orlitzky via mailop wrote:
> For the same reason, I would recommend verifying the addresses against a
> simple regular expression to catch typos, rather than against the full
> rfc5322 grammar which allows basically anything.
Hopefully not the one which is used on mo
On Sat, Nov 23, 2019, Tom Ivar Helbekkmo via mailop wrote:
> In the olden days, one would simply write a script, using expect(1) or
> similar, to go through the addresses, connect to the target MTAs, and do
> an SMTP VRFY on the recipient address. Today, I suspect that most MTAs
Some MTAs have a
On Thu, Nov 21, 2019, Carl Byington via mailop wrote:
> My servers have Let's Encrypt certs for sendmail, and receive a fair bit
> of mail from mimecast.
Just to clarify: If I understand it correctly, there are configuration
options how to handle STARTTLS which mimecast customers can modify,
e.g.
In general I block HTML only mail -- but I have to explicitly
whitelist some important (e.g., financial) senders.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
On Wed, Sep 18, 2019, Michael Rathbun via mailop wrote:
> opened or clicked within the past four months, and says, essentially, "If you
> want to continue to receive email from us, click here. Otherwise, you won't
I hate that stuff... beside the annoyance of requiring web stuff
to receive info v
On Thu, Nov 15, 2018, Michael Peddemors wrote:
> Nov 14 10:17:36 magic03 msd[5860]: RCPT blocked by server-wide checks.
> Nov 14 10:17:36 magic03 msd[5860]: DATA command received, args:
> Nov 14 10:17:36 magic03 msd[5860]: RCPT first error
> Ummm.. you don't keep trying to force DATA down the pip
On Tue, May 22, 2018, Steve Atkins wrote:
> If you're connecting to an MX that only supports TLS 1.0 and you've
> configured your smarthost to not support TLS 1.0 for opportunistic
> encryption then it's going to fall back to not using any sort of encryption
> and sending as plaintext.
That depen
Just a note:
draft-santos-smtpgrey suggests to tell the sender when to try again,
e.g., 451 Greylisted, please try again in # seconds
Maybe something like that would be the right approach for this case
too? You could announce the limits for the client in the greeting,
e.g.,
250-CONCURRENT-CONNECT
On Mon, Feb 13, 2017, John Levine wrote:
> >How would a user know that (s)he missed a mail?
> They're expecting something and don't get it. It's certainly happened
Well, I gave an example where a user isn't "expecting something"
and still missed mails that would have been useful for her/him
with
On Mon, Feb 13, 2017, John Levine wrote:
[blocking mails/nets]
> that /16 formany years, with never a user complaint. If the mail logs
How would a user know that (s)he missed a mail?
I sometimes send patches to various open source projects and if a
mail to the maintainer bounces due to some "an
Is the bh= value correct? AFAICT that would mean the headers have
been modified -- which can be the case if sendmail is involved and
it gets bogus input (e.g., from broken M$ MUA not using the proper
syntax).
BTW:
$ dkim-vrfy.pl < yourmessage
signature identity: @five-ten-sg.com
verify result: fai
On Wed, Nov 02, 2016, Jim Cheetham wrote:
> On the face of that, I'm going to recommend raising our
> MaxHeadersLength from 32768 to 262114 in the current production
> servers, and to 1MB for the next iteration of servers.
If you run milters, you might have to change some more settings.
Check the
On Sun, Oct 30, 2016, Bill Cole wrote:
> >>200 Welcome to my server
> >RFC 2821:
> > Greeting = "220 " Domain [ SP text ] CRLF
> >So two problems in the initial greeting already...
> Well, the lack of ESMTP is entirely not a problem at all, so there's only
I didn't write anything about "l
Funny how someone with a broken SMTP server complains about broken
SMTP clients...
> 200 Welcome to my server
RFC 2821:
Greeting = "220 " Domain [ SP text ] CRLF
So two problems in the initial greeting already...
--
Please do not Cc me; use the list.
___
On Tue, Jun 14, 2016, Jeffry Dwight wrote:
> MAIL FROM:
> RCPT TO:
RFC 5321 SMTP October 2008
...
Since it has been a common source of errors, it is worth noting that
spaces are not permitted on either side of the colon following FROM
in th
On Thu, May 12, 2016, Jeffry Dwight wrote:
> Is it even worth checking the cert chain at all?
Sure, if you want to enable further requirements.
For example, I use something like this:
smtpc_rcpt_conf:@$IMPORTANTDOMAIN tls_requirements { flags={verified};
cipher_bits_min=256; hostnames = {
On Thu, May 12, 2016, Jeffry Dwight wrote:
> So, what do you all do? Right now, I'm verifying the cert and its chain, but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but
Only log "problems" (why should I trust some CA?) unless explicitly
configured to check (for a few
Maybe they run into something like this?
220 126.com Anti-spam GT for Coremail System (126com[20140526])
EHLO
Connection to 126mx02.mxmail.netease.com closed by foreign host.
It takes a long time to get any reply... and then your sever
simply closes the connection.
And from a different sys
94 matches
Mail list logo
