Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Paul Gregg via mailop]

On Fri, Mar 08, 2024 at 02:15:21PM +0100, Marco Moock via mailop wrote:
> Can you test 53/udp and 53/tcp on their authoritative NS from home?

pgregg@pgsurfacepro8:~$ dig +short +tcp soa freenet.de @ns1.fdkcloud.de.
ns1.fdkcloud.de. hostmaster.freenet-business.de. 2024030701 28800 7200
604800 3600
pgregg@pgsurfacepro8:~$ dig +short +tcp soa freenet.de
@ns1.fdkcloud.net.
ns1.fdkcloud.de. hostmaster.freenet-business.de. 2024030701 28800 7200
604800 3600

pgregg@pgsurfacepro8:~$ dig +short soa freenet.de @ns1.fdkcloud.de.
ns1.fdkcloud.de. hostmaster.freenet-business.de. 2024030701 28800 7200
604800 3600
pgregg@pgsurfacepro8:~$ dig +short soa freenet.de @ns1.fdkcloud.net.
ns1.fdkcloud.de. hostmaster.freenet-business.de. 2024030701 28800 7200
604800 3600

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Paul Gregg via mailop]

On Fri, Mar 08, 2024 at 01:26:48PM +0100, Stefano Bagnara via mailop wrote:
> On Fri, 8 Mar 2024 at 13:17, Marco Moock  wrote:
> > Can you access their website on freenet.de from OVH?
> 
> No. I can't even reach their NS from OVH network.
> So I can't resolve www.freenet.de: but if I try with the IP, then I
> can't ping it.

I can confirm your observations.  I can't see their NS from my OVH box,
nor can I connect to port 25 of the 3 IPs behind their MX.
From home (UK broadband), I can see and query DNS servers, but I can't
talk to port 25.
From non-home/non-ovh, I can see DNS and talk to port 25.

They do claim to use RBLs, but my OVH IP isn't on any RBLs (not even
uceprotect-L3 amazingly right now) - and based on my home 'DUL' IP not
being able to connect, they're certainly using RBLs on port 25.
It also looks like there might be a separate transit issue with OVH.
Might be deliberate, might not.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verifying receipients?

[Paul Gregg via mailop]

On Fri, Feb 16, 2024 at 02:49:12PM -0600, Jesse Hathaway via mailop wrote:
> Does probing for recipients work these days, is it considered abusive?

It rarely works they way you might hope. And yes, we consider it
abusive.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Proofpoint mailop contact?

[Paul Gregg via mailop]

On Fri, Jan 05, 2024 at 04:37:41PM -0500, Thomas Johnson via mailop wrote:
> Hello-
> 
> We're seeing some dropped connections from various servers on ppe-hosted.com 
>  - the Proofpoint hosted service.
> 
> I'd like to discuss with an admin there, but I cannot locate any contact 
> information online for them.
> 
> Is anyone from Proofpoint on here? Or does anyone have a contact?
> 
> Please feel free to conact me offlist, if that's preferred.

Responded off-list.

Short version... We connect, don't receive a greeting, timeout and
disconnect.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Thoughts on envelope address local-part length limits

[Paul Gregg via mailop]

On Fri, May 12, 2023 at 05:54:28PM +, Slavko via mailop wrote:
>  Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop 
>  napísal:
> 
>  >4.5.3.1.  Size Limits and Minimums
> 
>  When you read RFC, you MUST read all, not only interesting parts.
>  Yes, sometime it is hard, but notice the sentence in this section:
> 
>  Every implementation MUST be able to receive objects of at
>  least these sizes.
> 
>  I understand that these limits are not maximum which can be
>  used, but rather minimum which have to be supported. That
>  is shown in the same section latter:
> 
>  To the maximum extent possible, implementation techniques
>  that impose no limits on the length of these objects should be
>  used.
> 
>  It IMO clearly suggests to not limit these things.

I'm not here to throw stones at semantic reasoning, but it is really
difficult to read "The maximum total length of " to mean "support
this at a minumum but feel free to blow way past it".

My original question was if the 64 octet limit is pointless now.
Seems like it is.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Thoughts on envelope address local-part length limits

[Paul Gregg via mailop]

I'd like to start a discussion on folks opinions(*) on enforcing
Envelope Sender/Recipient local-part length limits.

*opinions - because no mail operator seems to agree what it should be.

For context, RFC5321 defines local-part (the bit of an envelope address
to the left of the @ in an email address as) in the Size Limits and
Minimums section as:
4.5.3.1.  Size Limits and Minimums
...
4.5.3.1.1.  Local-part

   The maximum total length of a user name or other local-part is 64
   octets.


You'll find lots of people talking about this if you google, but they
mostly seem to refer to RFC822 (and subsequents) not being explicit
(obviously missing the point that 822 is about the Headers while 821 is
for SMTP protocol).
821, 2821, 5321 and errata have increasingly clarified this towards:
- local-part max is 64 bytes (including the <) so really 63 octets
- domain max is 255 octets
- max total path is 256 octets

We (Proofpoint Essentials) recently began enforcing <64 octets for the
local-part of an envelope address. However, we are seeing a lot of
senders using way longer than this.

For example, looking at yesterday's traffic, 90% use 64 octets (so 65
when you include the <)
Another 3-4% live in the 65-69 octets range
2% at 73/74 octets...
The largest was 217 octets

None of these are 'user' addresses, they're all bounce identification,
verp / recipient identifying or look like exchange distro list with AD
encodings.  They come from some big names, amazon, salesforce, etc.

I suspect with verp/bounce addressing widely in use now, 64 octets just
isn't enough these days.

So, my question(s) to mailop - Is the 'local-part' definition no longer
fit for purpose? Has that horse already bolted? Do you impose any limit
and if so, what?

Thanks,
PG

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Proofpoint contact needed - Duplicate ticket for IP block removal issue

[Paul Gregg via mailop]

On Tue, May 02, 2023 at 08:04:35AM +, Andy Onofrei via mailop wrote:
> Can anyone has a way to reach out to Proofpoint, my contacts are unresponsive 
> for the last weeks, after MAWWG.
> I have a ticket with status unresolved for several weeks, they seem to be 
> stuck on their queue.

Contacted offlist.

Thanks,
PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before 250 OK

[Paul Gregg via mailop]

On Tue, Mar 07, 2023 at 01:35:12PM -0500, David Sovereen via mailop wrote:
>  [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] cmd: DATA
>  [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] Performing PTR host 
> name lookup for 204.101.223.59
>  [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] PTR host name for 
> 204.101.223.59 resolved as esa2-dor.bell.ca
>  [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] rsp: 354 Start mail 
> input; end with .
>  [2023.03.06] 13:43:28.810 [204.101.223.59][57867550] senderEmail(2): 
> redac...@bell.ca parsed using: “Redacted” 
>  [2023.03.06] 13:43:28.810 [204.101.223.59][57867550] Sender accepted. 
> Weight: 4. Block threshold: 36. Failed checks: _SPF (4,None)
>  [2023.03.06] 13:45:33.408 [204.101.223.59][57867550] rsp: 421 Command 
> timeout, closing transmission channel
>  [2023.03.06] 13:45:33.408 [204.101.223.59][57867550] disconnected at 
> 3/6/2023 1:45:33 PM
>  [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] rsp: 250 OK
>  [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Client socket is 
> disconnected! Disconnect exception encountered: True, IsDisconnected: True, 
> This message will still be accepted. 
>  [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Received message size: 
> 17588 bytes
>  [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Successfully wrote to 
> the HDR file. (d:\mail\spool\SubSpool9\1391309161820.hdr)
>  [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Data transfer 
> succeeded, writing mail to 1391309161820.eml (MessageID: )

This log looks like you timed out the bell.ca sending server after 2
minutes. You closd the connection - and so how do you expect them to
send a QUIT?

Additionally - you aborted the stream mid-DATA command - you have 1) no
guarantee thatyou've received the whole message*** and 2) bell.ca has no
confirmation that you've received the message - so their server will
retry.

*** If you know you received the whole message (i.e. bell.ca sent the
CRLF.CRLF and you're now 'doing your thing' before deciding to accept or
reject the message) then you've set your 2 minute timeout way too low
and you need to work out how to complete your processing within your own
timeout.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] problem sending messages to gmail

[Paul Gregg via mailop]

On Tue, Jan 17, 2023 at 11:31:22AM -0500, John Covici via mailop wrote:
>  Hi.   For some reason this morning, I am having problems sending to
>  gmail addresses.  I get the following error for each:
> 
>  <<< 550-5.7.1 [166.84.7.93  12] Our system has detected that this
>  message is
>  <<< 550-5.7.1 likely unsolicited mail. To reduce the amount of spam
>  sent to Gmail,
>  <<< 550-5.7.1 this message has been blocked. Please visit
>  <<< 550-5.7.1
>  https://support.google.com/mail/?p=UnsolicitedMessageError
>   Now I have had no problems sending to gmail, but this message was
>   send to maybe 40 users or so -- is this my problem, or am I doing
>   something else wrong?
> 
>  Thanks in advance for any suggestions.

Yes, we also started seeing these in the past 60 or so hours. In this
case, the message is rejected (and not delivered to the user) and
(likely) and NDR is sent back.

I should note that within the past hour - things look to be
significantly improved. Mail is making it to Inboxes - and seeing
significantly fewer 550-5.7.1 responses.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail putting most messages into Spam

[Paul Gregg via mailop]

On Tue, Jan 17, 2023 at 08:28:54AM -0600, Mark Alley via mailop wrote:
> Just to clarify - Do you mean from Proofpoint enterprise (PoD) customers or
> Proofpoint essentials? I could definitely see essentials having this problem
> as their IP space is shared amongst customers, but PoD clusters each
> individually have their own IPs that are separate from any other customer.
> 
> On 1/17/2023 8:15 AM, Jeff via mailop wrote:
> > We too have been seeing this in the last 48 hours
> > 
> > Only from clients sending out from Proofpoint though and Google is
> > marking them as Spam for the reason "Blatant Spam"... when they are
> > clearly not
> > 
> > We have tickets open with all relevant providers (Proofpoint and Google)
> > to see if we can figure this out

In my case, Proofpoint Essentials*. Tho a post in r/msp about this same
issue last night also suggests folks are seeing it from PoD and even
when they removed Proofpoint from the path and sent O365->Gmail
directly.

Disclosure: * I'm the Eng Manager responsible for the Essentials
Platform.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail putting most messages into Spam

[Paul Gregg via mailop]

On Tue, Jan 17, 2023 at 02:50:04PM +0100, Peter N. M. Hansteen wrote:
>  Just a wild guess based on experience - do those deliveries happen over IPv6?

In this case, no.  We* only have IPv4 throughout the stack - IPv6 is
disabled everywhere.

*Proofpoint Essentials

I did think it might be TLS - but every test I've seen did hand off to
gmail over TLS - so not that.

Regards,
PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] gmail putting most messages into Spam

[Paul Gregg via mailop]

Heads up in case anyone else is experiencing this.

We are aware of a recent change in behaviour of gmail.com where
most email is placed directly into Spam folder.

So far we have dozens of customers reporting this.
Tested myself with full SPF, DKIM and DMARC with p=reject - which gmail
itself marks as passing all tests. The mail was also delivered over TLS.
Mails go to Spam.

We're trying to reach out to google, but so far have no response.

We don't think it is just 'us', as reddit r/msp has others reporting
same from O365 direct to gmail.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Paul Gregg via mailop]

On Thu, Apr 14, 2022 at 06:34:07AM -0700, Dave Crocker via mailop wrote:
> 
> Folks,
> 
> This was just issued. It will aid in evaluating handling history of a
> messsage, especially through aliasing and mailing list sequences.
> 
> d/
> 
>  Forwarded Message 
> Subject: RFC 9228 on Delivered-To Email Header Field
> Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> RFC 9228
> 
> Title:  Delivered-To Email Header Field
> Author: D. Crocker, Ed.
> Status: Experimental
> Stream: Independent
> Date:   April 2022
> Mailbox:dcroc...@bbiw.net
> Pages:  10
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-crocker-email-deliveredto-10.txt
> 
> URL:https://www.rfc-editor.org/info/rfc9228
> 
> DOI:10.17487/RFC9228
> 

Whilst I understand the Delivered-To: header isn't explicitly codified
in an RFC - I don't think there is anything here that we haven't all been
using for a *long* time already.

Author seems to argue that 'new' use is list explosion and forwarding
which is trivially disproven by prior-art.

Specifically DJB's draft of 26 years ago:
https://datatracker.ietf.org/doc/html/draft-bernstein-mail-loops-war-00
which explicitly calls out such uses as Dave thinks is new.

Sure, ressurect the proposal and push for standards track - but credit
needs to go to Dan, not Dave.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best email server for home use...

[Paul Gregg via mailop]

On Thu, Feb 24, 2022 at 06:38:24PM +0100, Jaroslaw Rafa via mailop wrote:
> And in this particular case we are discussing, not only a VPS is involved,
> but also a 3rd party service that acts both as a MX for incoming mail and as
> an outgoing SMTP server that actually delivers mail to recipients. The OP
> even said that the VPS could be omitted, but the 3rd party service is
> essential for him. For me, that definitely doesn't qualify as self-hosting.

To be fair (to me), the 3rd party service is only new in the past 3
years. Prior to that, communication to/from the internet was a Kimsufi
(OVH) colo box.  Perhaps I was lucky in that my IP wasn't listed in any
blocklists.  I'd 'self-hosted' like that for over 20 years.

The VPS could be omitted.  Alternatively the 3rd party service could be
omitted if you can find yourself a decent IP that the world won't block
either via a VPS or VPN.

I wouldn't say the 3rd party serive is 'essential' - or maybe that was
the pun because it is 'Proofpoint Essentials' :)   As noted, it is a
relatively new addition to my setup - and I chose to do that more for
the email security aspects (I no longer care about running spamassassing
or clamav, etc).

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best email server for home use...

[Paul Gregg via mailop]

On Wed, Feb 23, 2022 at 01:19:47PM -0500, John Levine via mailop wrote:
> It appears that Sinclair, John via mailop  said:
> > I have the hardware and the bandwidth, ...
> 
> More importantly, do you have a static IP with matching forward and reverse 
> DNS that
> is not in the PBL or otherwise policy blocked for sending mail?
> 
> By the time you go through all the hassle of managing spam filters and 
> getting your
> IP warmed up, Fastmail at $50/yr/mailbox looks pretty attractive.
> 
> If you can find someone who resells Tucows' white label e-mail, they have a 
> pretty
> good product for about $10/mailbox/yr for 5GB, $20 for 10GB, $30 for 15GB.
> 
> R's,
> John

I've run my own mailserver at home, usually on a dynamic IP, for over 25
years now. Started with qmail (Hi John), now postfix / dovecot and
letsencrypt for the certs.

It's definitely gotten more difficult to successfully do this of late,
but I've a solid system now. Might not be what anyone wants or needs,
but who knows, if it helps someone...

Local server in the house (dell r720xd - too big, but heh)
- Custom domains for me and all family members (this is usually what stops
  me hosting on another provider).
- Obviously as much disk as I want to throw at it.
- Connected to my DSL provider using a dynamic IP.
- Letsencrypt generates the certs

VPS on OVH (usually this is a bad idea, but actually this step isn't
necessary)
- Runs postfix, and a dyndns server
- Local server has a cron job to contact this vps to inform it 'this is
  my IP' and 'here is my certificate fingerprint'
- Server also runs a firewall and only allows this dynamic IP to talk to
  it and the internet facing mail service.
- None of this bit is strictly necessary - except a dynamic dns service
  (and you'd need to use SMTP Auth config from LocalServer to ESP)

3rd Party Email security provider - using Proofpoint Essentials*
- *disclaimer - I work for them, 3rd party/partner resellers do resell
  it pretty cheaply
- MX for my domains goes to Essentials, Inbound traffic is sent to my
  interim VPS
- Outbound email is received from the VPS and Essentials takes care of
  deliverability out to everyone else.

The VPS middle layer isn't really necessary - I just prefer it as it
means I've a buffer in case Proofpoint caches the DNS a little too long
and I can use it to validate the cert on the local server when it
connects (should my dynamic IP change and I don't send my email to some
rando).

So I concur with John... it is perfectly possible to host yourself if
you can get past things like 'dialup rbls' and other poor reputation
blocks.  It's often easier just to let established providers do that
bit.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Feasibility of a private DNSBL

[Paul Gregg via mailop]

On Wed, Oct 06, 2021 at 10:22:11AM +0200, Leandro Santiago via mailop wrote:
> Thank you all who shared their knowledge.
> 
> We decided, on our solution, to go away from the DNSBL approach which has
> way too many caveats and are now experimenting with solutions on a higher
> level on the network stack.
> 
> On 10/4/21 18:52, Leandro Santiago via mailop wrote:
> > Hi list,
> > 
> > How feasible to you folks think having a DNSBL server that accepts only
> > connections from a group of IP is?
> > 
> > By that I mean that the server will accept (UDP) DNS requests from an
> > "allow list", refusing requests from anyone else (basically answering
> > "nothing" from any dns question from other IP addresses). I am using the
> > IP from the UDP request packet to perform the "authentication".
> > 
> > This is for a DNSBL which is not supposed to be public, although the DNS
> > server is accessible publicly on the internet. I want to keep the DNSBL
> > "spec", so for a request:
> > 
> > A 44.33.22.11.myserver.example.com.
> > 
> > I'll answer, in case 11.22.33.44 is "blocklisted":
> > 
> > A 127.0.0.2

Sorry for the late reply.

The trick to this is not to limit by IP address - but to implement
service (API) keys.

e.g. each authorised user is given a key e.g. sj3Fa3Gomd937Z12

Then they make queries for 44.33.22.11.sj3Fa3Gomd937Z12.myserver.example.com.

That way you don't care what IP it comes from, but you know who it is.

PG
Sent via Proofpoint Essentials https://proofpointessentials.co.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Info - DMARC at WEB.DE, GMX, mail.com coming soon

[Paul Gregg via mailop]

On Thu, Apr 01, 2021 at 04:51:34PM +0100, Laura Atkins via mailop wrote:
> 
> 
> > On 1 Apr 2021, at 15:36, Marcel Becker via mailop  wrote:
> > 
> > On Thu, Apr 1, 2021 at 12:43 AM Hans-Martin Mosner via mailop 
> > mailto:mailop@mailop.org>> wrote:
> > 
> > One option that you should consider to mitigate the effects for recipients 
> > is to allow per-recipient DMARC exceptions, because the recipient is the 
> > one who ultimately decides whether mail is wanted or unwanted.
> > 
> > Recipients are the ones least able to make a decision whether a mail 
> > claiming to be from brand.com  was really sent from 
> > brand.com . They don't even know that a mail from 
> > lookslikebrand.com  is not legit, move it out 
> > of the spam folder and then proceed to interact with it…
> 
> And half of the time looklikebrand.com is actually said brand. 
> 
> laura 

And even if lookalikebrand.com is a fake/phish - the sender is either going to 
not have
DMARC/SPF records or they're going to set them up to be perfect - in either 
case,
this argument is irrelevant.

PG


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Gregg via mailop]

On Thu, Feb 04, 2021 at 02:57:43PM +, Paul Gregg via mailop wrote:
> On Thu, Feb 04, 2021 at 12:03:45PM +, Paul Smith via mailop wrote:
> > On 04/02/2021 11:39, Paul Gregg via mailop wrote:
> > >It sounds like you are using PIPELINING when the remote doesn't support it 
> > >(properly).
> > >See if you can turn off pipelining (at least to that endpoint) on your 
> > >client side.
> > 
> > What is the server doing incorrectly with the pipelining?
> > 
> 
> > > > 250 2.1.0 OK
> > > > 250 2.1.5 OK
> > > > 250 2.1.5 OK
> > > > 452 4.5.3 Please resend separately
> > > > 452 4.5.3 Please resend separately
> > > > 250 2.1.5 OK
> > > > 250 2.1.5 OK
> 
> I'd expect the Server response to provide the rcpt to address in the address 
> per rfc2920
> 
> 
>C: EHLO dbc.mtview.ca.us
>S: 250-innosoft.com
>S: 250 PIPELINING
>C: MAIL FROM:
>C: RCPT TO:
>C: RCPT TO:
>C: RCPT TO:
>C: DATA
>S: 250 sender  OK
>S: 250 recipient  OK
>S: 250 recipient  OK
>S: 250 recipient  OK
> 
> 
> Absent the rcpt address in the server response, the client relies on the 
> server MUST respond to commands in the order they are
> received - and the original post suggests that isn't the case either.

Replying to my own message. Went back and looked at the exim log from OP... 
seems the ordering was correct - so that means exim is
screwing it up. I'd still recommend disabling pipelining on the client side.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Gregg via mailop]

On Thu, Feb 04, 2021 at 12:03:45PM +, Paul Smith via mailop wrote:
> On 04/02/2021 11:39, Paul Gregg via mailop wrote:
> >It sounds like you are using PIPELINING when the remote doesn't support it 
> >(properly).
> >See if you can turn off pipelining (at least to that endpoint) on your 
> >client side.
> 
> What is the server doing incorrectly with the pipelining?
> 

> > > 250 2.1.0 OK
> > > 250 2.1.5 OK
> > > 250 2.1.5 OK
> > > 452 4.5.3 Please resend separately
> > > 452 4.5.3 Please resend separately
> > > 250 2.1.5 OK
> > > 250 2.1.5 OK

I'd expect the Server response to provide the rcpt to address in the address 
per rfc2920


   C: EHLO dbc.mtview.ca.us
   S: 250-innosoft.com
   S: 250 PIPELINING
   C: MAIL FROM:
   C: RCPT TO:
   C: RCPT TO:
   C: RCPT TO:
   C: DATA
   S: 250 sender  OK
   S: 250 recipient  OK
   S: 250 recipient  OK
   S: 250 recipient  OK


Absent the rcpt address in the server response, the client relies on the server 
MUST respond to commands in the order they are
received - and the original post suggests that isn't the case either.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Gregg via mailop]

On Thu, Feb 04, 2021 at 11:37:05AM +0100, Benoît Panizzon via mailop wrote:
> Hi List
> 
> We managed to reproduce the issue while sniffing the SMTP connection.
> 
> From my observation, I suppose it's a bug in EXIM as it encounters a
> situation which probably is somehow unique with our spamfilter.
> 
> So how to reproduce... The focus is on the MAIL FROM / RCPT TO lines in
> the SMTP dialogue.
> 
> Exim is sending the MAIL FROM and RCPT TO lines in one go, without
> waiting for the reply of the recipient server.
> 
> Example:
> 
> MAIL FROM: s
> RCPT TO: a
> RCPT TO: b
> RCPT TO: c
> RCPT TO: d
> RCPT TO: e 
> RCPT TO: f
> 
> Now the server in return replies with one line for each of those
> commands:
> 
> 250 2.1.0 OK
> 250 2.1.5 OK
> 250 2.1.5 OK
> 452 4.5.3 Please resend separately
> 452 4.5.3 Please resend separately
> 250 2.1.5 OK
> 250 2.1.5 OK
> 
> In this case, the recipients c + d did tempfail.
> 
> BUT Exim is logging that emails were delivered 200 OK to c + d and is
> putting e + f in the 'retry' queue.
> Subsequently, c + d never get the email and e + f are getting
> duplicates.

It sounds like you are using PIPELINING when the remote doesn't support it 
(properly).
See if you can turn off pipelining (at least to that endpoint) on your client 
side.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MessageLabs "cluster1a*" MX records

[Paul Gregg via mailop]

On Tue, Jan 26, 2021 at 03:52:49AM -0700, Luke via mailop wrote:
> Starting very precisely on January 6th, we started to see a number of
> previously reliable domains turn up with secondary MX records that look
> like these:
> 
> cluster1a.us.messagelabs.com
> cluster1a.eu.messagelabs.com
> cluster1a.uk.messagelabs.com
> 
> The domains with these secondary records have primary mx records that look
> like these:
> 
> cluster1.us.messagelabs.com
> cluster1.eu.messagelabs.com
> cluster1.uk.messagelabs.com
> 
> Starting on January 6th, successful deliveries to these domains declined
> about 50%, but did not drop to zero. Engagement at these domains has
> remained steady. However we are now seeing *tons *of *421 Service
> Temporarily Unavailable *responses from the secondary MX records while
> still seeing successful deliveries to the primary MX record.
> 
> Curious to hear if anyone else is seeing something similar or if anyone
> can help me understand what might be going on with these cluster1a* MX
> records.
> 
> Here are a few example domains:
> 
> funaisoken.co.jp
> cimb.com
> stockland.com.au
> travelex.com
> 
> Would love to hear any thoughts or insights.
> 
> Cheers,
> Luke

Can't really help other than to say we don't see anything like that.

Looked at logs for yesterday - precisely zero 421 Service Temporarily 
Unavailable responses from cluster1a? (both).
Some for other clusters, e.g. cluster10a

If stats helps, we delivered over 15,000 messages to cluster1.(us|eu|uk) - but 
zero to cluster1a - didn't need to drop to lower prio mx

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Gregg via mailop]

On Fri, Jan 22, 2021 at 08:24:24AM +0100, Benoît Panizzon via mailop wrote:
> Hi Paul and Gang
> 
> I have been testing with our Exim and Postfix.
> 
> Everything works as expected. If Postfix rejects a recipient with 452
> Exim is immediately re-sending that recipient with a new SMTP session.
> 
> But the customer affected can 100% reproduce the issue.
> 
> What I observed is that EXIM keeps on trying every recipient even after
> receiving 452 which signals that we reached the maximum recipients. So
> there would be no point in EXIM trying all remaining recipients after
> hitting the first such error.

This should be expected. As others have noted, 452 is just postfix telling the
sender that there is a temp error for that recipient. The sending server
will normally carry on with the rest of the recipients.

> So I wonder, if later EXIM encounters a recipient that is accepted,
> would that trigger the 'BUG' that the previous recipients are also
> considered as having been accepted?
> 
> Thank you about the hint to RFC5321 (draft standard)
> 
> Yes indeed we violate this RFC. I was not aware of that. But this RFC
> also breaks established spam filtering techniques by stating an MTA
> must accept at least 100 recipients.
> 
> I guess I'll notify the author about that issue so hopefully that can
> be avoided when this is made a standard.

I'd point out that this exact same wording is in RFC2821 (predecessor to
5321) and similar wording for minimum recipients in RFC821.  This is
*well* established for the last 38 years.
rfc5321 is not going to change that wording.

> Problem:
> 
> Let's first set some guidelines we want to observe while fighting spam.
> 
> * An email shall never 'disappear'. When the MTA accepted the Email
>   with 200 OK it is to be delivered to the RECIPIENT. If the delivery
>   to the RECIPIENT is not possible (invalid destination address, Quota
>   Full, Spam) the email is to be rejected during the SMTP Session.
> 
> * Backscatter is to be avoided! That is why an unacceptable email is to
>   be rejected during SMTP Handshake and not as 'bounce'.
> 
> Now Assume two recipients with different Anti-Spam Settings:
> 
> Recipient A: REJECT Spam.
> Recipient B: Tag Subject and Deliver Spam to 'Spam' Folder.
> 
> During he RCPT TO phase of the SMTP Dialogue, we don't have the content
> of the email yet, thus we don't know if that email will later be
> identified as spam or not.
> 
> If it will be identified as SPAM, we have two contradicting actions to
> perform. We CANNOT reject AND accept the Email after the DATA Phase.
> 
> But during the RCPT TO Phase, we can look-up the spam settings of the
> recipient. If they contradict, we can reject the recipients with
> settings which contradict the first recipient with 452 which according
> to our tests with many MTA always showed to cause the sending MTA to
> immediately open a second SMTP session for the remaining recipients.

It does sound like the issue (at least with dropping the 452 rcpt on the
floor) lies with your customer.

I'd also challenge some of your assumptions. I'm not sure limiting max
recipients at the smtp conversation stage is an established technique.

If you wish to apply filters based on the content of the message, then you
need to (obviously) wait until after the DATA stage - but any disposition
you put on the message (perhaps from a single RCPT choice of filters) would
then apply to all recipients - so rejecting the message is not applicable
here.

I think you might need to accept that you may need more use of the Spam /
Quarantine folder than you expected. You clearly understand the challenges
here.  The only thing you can really do at the RCPT stage is specific
user filters blocking the MAIL FROM or sending server (typically sending
 server is handled globally via RBLs).

Paul

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Paul Gregg via mailop]

On Thu, Jan 21, 2021 at 09:48:51AM +0100, Benoît Panizzon via mailop wrote:
...
> mail from:
> 250 2.1.0 Ok
> rcpt to:
> 250 2.1.5 Ok
> rcpt to:
> 452 4.5.3 Incompatible Antispam Action, please resend this recipient
> separately
> 
> And that is exactly what I expected and what see in our logs...
> So Postfix is NOT accepting the second recipient with 200 OK and
> logging it has been tempfailed.
> 
> So now I am more confident this has to be an EXIM bug.
> 
> What I suppose is happening there is: One recipient was accepted.
> 
> From the Log the ISP using EXIM sent me. I see the return code is:
> 
> 250 2.0.0 Ok: queued as 16EC1C100A

Note that this response is the response from the DATA command, not the RCPT

It's possible Exim is happily blasting through all the RCPT commands, ignoring 
all the 452
recipients, then DATA sending to the one(s) that Postfix 250 Ok-ed.
Postfix rightly then gave a 250 response with the Queue Id, which Exim logged 
and it looks
as if the mail was delivered properly.

> Yes, or course, that email got queued under that ID on our side. The
> FIRST recipient was valid.
> 
> So does EXIM falsely apply that 200 OK also to subsequent tempfailed
> recipients in the same SMTP connection?
> 
> We have a voicemail server running EXIM. Going to try to reproduce the
> issue there.

It's not clear to me what your? postfix / anti-spam software setting is for 
number
of receipients per message?   If it is <100 then you're breaking RFC5321
minimum number of recipient buffer.

On the Exim side, set max_rcpt to 100 or less.

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Firefox Relay

[Paul Gregg via mailop]

On Fri, Dec 18, 2020 at 11:52:31AM +, Andrew C Aitchison via mailop wrote:
> 
> I note a new service: Firefox Relay
>   https://relay.firefox.com
> 
>As you browse, the Relay icon will appear in form fields where
>sites ask for your email address. Select it to generate a new,
>random address that ends in @relay.firefox.com. Relay will forward
>messages to the primary email address associated with your account.
> 
> I guess we need to prepare for forwarded emails to our users via a new
> intermediate.
> 
> I guess that some email services will either fail to, or chose not to,
> accept these messages.

anon.penet.fi is reborn :)

PG
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop