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] Bell.ca servers disconnecting before QUIT

[Gellner, Oliver via mailop]

On 2023-03-07 18:59, Bastian Blank via mailop wrote:
> On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:

>> 1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, our 
>> users cannot receive any bell.ca  mail.
> SMTP servers don't send e-mail, they receive e-mail.  You mean SMTP client.

People also refer to machines or the actual physical hardware on which daemons 
are running as "servers". If you eg execute curl on such a system, then the 
server is initiating a HTTP connection.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Michael Peddemors via mailop]

Still far too many email platforms not following RFC's on this, thinking 
it will improve performance, they just exit at 250ok..


First thing, make sure you have pipelining turned off.. not that it is 
your problem, but it will help you out..


Of course, by your description this sounds like a case of both parties 
being at fault.. You should not be getting duplicates..  something else 
seems to be an issue..


And confirmed in our logs that bell IS issuing the QUIT, and even 
waiting for the response..


It could be that you are taking too long, or have a post data filtering 
system taking too long, or your session is ending..


Without looking at more detailed logs.. really hard to help you.

On 2023-03-07 09:26, David Sovereen via mailop wrote:

Hello,

I’m trying to reach someone at bell.ca  who can help us 
with two inter-related issues.


1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, 
our users cannot receive any bell.ca  mail.


2.  If we accept without a QUIT, our users occasionally get duplicate 
messages and sometimes LOTS of duplicate messages.


Is anyone else seeing this issue?

If someone from bell.ca  is out there, I’d appreciate an 
email off-line.


Thanks,

Dave

*David Sovereen*
**
Mercury Network Corporation
2719 Ashman Street, Midland, MI 48640
989.837.3790 x151 office | 888.866.4638 toll free | 989.837.3780 fax
Telephone*  | *Internet*  | *Hosting
david.sover...@mercury.net 
www.mercury.net 



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



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

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

[David Sovereen via mailop]

There is a 120 second command timeout configured, so it would seem there was 
activity for about 5 seconds, then nothing for 120 seconds and the command 
timeout was reached causing the software to close the connection.

We’re a small operation running on Smartermail 
(https://www.smartertools.com/smartermail/business-email-server) and host about 
5,000 mailboxes.  No issues except that one of our customers has regular 
trouble receiving mail from bell.ca.

The server runs on bare metal Supermicro with Intel NICs.

Dave

> On Mar 7, 2023, at 2:34 PM, Bill Cole via mailop  wrote:
> 
> On 2023-03-07 at 13:35:12 UTC-0500 (Tue, 7 Mar 2023 13:35:12 -0500)
> David Sovereen via mailop 
> is rumored to have said:
> 
> 
> [Abridged for clarity. Only the SMTP chat is left...]
> 
>> [2023.03.06] 13:43:28.748 [204.101.223.59][57867550] cmd: RCPT TO:
>> [2023.03.06] 13:43:28.748 [204.101.223.59][57867550] rsp: 250 OK Recipient ok
>> [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] rsp: 354 Start mail

>> [2023.03.06] 13:45:33.408 [204.101.223.59][57867550] rsp: 421 Command 
>> timeout, closing transmission channel
>> [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] rsp: 250 OK
> 
> What is happening in that 125-second gap? Why are *you* timing out after 125 
> seconds?
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop


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

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

[Tobias Fiebig via mailop]

On Tue, 2023-03-07 at 14:34 -0500, Bill Cole via mailop wrote:
> What is happening in that 125-second gap? Why are *you* timing out
> after 125 seconds?

To add to Bill's suggestion, given this happens after DATA: Check the
(path) MTU.

Btw, is there any hypothetical chance that your mailer might be running
on a KVM/QEMU virtualized platform and might be using rtl8139 virtual
NICs (no offense meant; this is a very wild guess, but from the looks
of it, your org. might fit the unlikely arrangement of stars and a full
moon that could lead to that.)

With best regards,
Tobias 

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

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

[Bill Cole via mailop]

On 2023-03-07 at 13:35:12 UTC-0500 (Tue, 7 Mar 2023 13:35:12 -0500)
David Sovereen via mailop 
is rumored to have said:


[Abridged for clarity. Only the SMTP chat is left...]


[2023.03.06] 13:43:28.748 [204.101.223.59][57867550] cmd: RCPT TO:
[2023.03.06] 13:43:28.748 [204.101.223.59][57867550] rsp: 250 OK 
Recipient ok

[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] rsp: 354 Start 
mail [2023.03.06] 13:45:33.408 [204.101.223.59][57867550] rsp: 421 
Command timeout, closing transmission channel

[2023.03.06] 13:48:59.847 [204.101.223.59][57867550] rsp: 250 OK


What is happening in that 125-second gap? Why are *you* timing out after 
125 seconds?


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Bastian Blank via mailop]

On Tue, Mar 07, 2023 at 01:29:37PM -0500, David Sovereen via mailop wrote:
> > On Mar 7, 2023, at 12:54 PM, Bastian Blank via mailop  
> > wrote:
> > On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:
> >> I’m trying to reach someone at bell.ca  who can help us 
> >> with two inter-related issues.
> > Why do you link to http://bell.ca/?  Or is that some unhelpful client
> > again?
> Yes, an unhelpful mail client.

And one that ignores the "Mail-Followup-To" header.

Please note that people on mailing lists usually don't want a personal
reply.  It is even considered rude, as this circumvents the filter that
moves mail into a different inbox.

> My apologies.  I was trying to get an email out quickly before running to a 
> meeting and completely mischaracterized the problem.  The problem is that the 
> *client* disconnects before receiving 250 OK.  Here’s a log:

> [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

421 is a hard error.  You must close the connection and abort the
transaction.  The client will not hear anything after that and retry.

> [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

This is bullshit.  After a disconnect, no transaction exists and no 250
reply can happen.

> [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)
> 
> If we accept delivery as we did here where they disconnect before we send 250 
> OK, the message gets delivered to our end user.  But the end user sometimes 
> gets duplicate messages, sometimes many duplicate messages.  If we don’t 
> accept messages from clients that stay connected until the 250 OK is given, 
> no bell.ca emails get through.

You are running into timeouts.  You have network problems or
synchronization issues.  Now you need to look at a real dump.  Use
wireshark.

Bastian

-- 
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
   stardate 3468.1.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[David Sovereen via mailop]

Ugh.  And my attempts at redacting yielded an incomplete log.  I’ve got to slow 
down.  Here is the complete log:

[2023.03.06] 13:39:02.921 [204.101.223.59][57867550] rsp: 220 mail.mercury.net 
[2023.03.06] 13:39:02.921 [204.101.223.59][57867550] connected at 3/6/2023 
1:39:02 PM 
[2023.03.06] 13:39:02.921 [204.101.223.59][57867550] Country code: CA 
[2023.03.06] 13:39:02.952 [204.101.223.59][57867550] cmd: EHLO ESA2-Dor.bell.ca 
[2023.03.06] 13:39:02.952 [204.101.223.59][57867550] rsp: 250-mail.mercury.net 
Hello [204.101.223.59]250-SIZE 69905066250-AUTH LOGIN 
CRAM-MD5250-STARTTLS250-8BITMIME250-DSN250 OK 
[2023.03.06] 13:39:02.983 [204.101.223.59][57867550] cmd: STARTTLS 
[2023.03.06] 13:39:02.983 [204.101.223.59][57867550] rsp: 220 Start TLS 
negotiation 
[2023.03.06] 13:39:03.077 [204.101.223.59][57867550] cmd: EHLO ESA2-Dor.bell.ca 
[2023.03.06] 13:39:03.077 [204.101.223.59][57867550] rsp: 250-mail.mercury.net 
Hello [204.101.223.59]250-SIZE 69905066250-AUTH LOGIN 
CRAM-MD5250-8BITMIME250-DSN250 OK 
[2023.03.06] 13:39:03.108 [204.101.223.59][57867550] cmd: MAIL FROM: SIZE=16961 
[2023.03.06] 13:39:03.108 [204.101.223.59][57867550] senderEmail(1): 
redac...@bell.ca parsed using: 
[2023.03.06] 13:43:28.716 [204.101.223.59][57867550] rsp: 250 OK Sender ok 
[2023.03.06] 13:43:28.716 [204.101.223.59][57867550] Sender accepted. Weight: 
4. Block threshold: 36. Failed checks: _SPF (4,None) 
[2023.03.06] 13:43:28.748 [204.101.223.59][57867550] cmd: RCPT TO: 
[2023.03.06] 13:43:28.748 [204.101.223.59][57867550] rsp: 250 OK Recipient ok 
[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: ) 

My apologies for the signal to noise ratio.

Dave

> On Mar 7, 2023, at 1:29 PM, David Sovereen via mailop  
> wrote:
> 
> 
>> On Mar 7, 2023, at 12:54 PM, Bastian Blank via mailop  
>> wrote:
>> 
>> Hi David
>> 
>> On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:
>>> I’m trying to reach someone at bell.ca  who can help us 
>>> with two inter-related issues.
>> 
>> Why do you link to http://bell.ca/?  Or is that some unhelpful client
>> again?
> 
> Yes, an unhelpful mail client.
> 
>> 
>>> 1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, our 
>>> users cannot receive any bell.ca  mail.
>> 
>> SMTP servers don't send e-mail, they receive e-mail.  You mean SMTP
>> client.  However an e-mail transaction ends with ..  So at
>> the time QUIT would be sent, no e-mail transaction is running.
> 
> My apologies.  I was trying to get an email out quickly before running to a 
> meeting and completely mischaracterized the problem.  The problem is that the 
> *client* disconnects before receiving 250 OK.  Here’s a log:
> 
> [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][5

Re: [mailop] Bell.ca servers disconnecting before QUIT

[David Sovereen via mailop]

> On Mar 7, 2023, at 12:54 PM, Bastian Blank via mailop  
> wrote:
> 
> Hi David
> 
> On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:
>> I’m trying to reach someone at bell.ca  who can help us 
>> with two inter-related issues.
> 
> Why do you link to http://bell.ca/?  Or is that some unhelpful client
> again?

Yes, an unhelpful mail client.

> 
>> 1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, our 
>> users cannot receive any bell.ca  mail.
> 
> SMTP servers don't send e-mail, they receive e-mail.  You mean SMTP
> client.  However an e-mail transaction ends with ..  So at
> the time QUIT would be sent, no e-mail transaction is running.

My apologies.  I was trying to get an email out quickly before running to a 
meeting and completely mischaracterized the problem.  The problem is that the 
*client* disconnects before receiving 250 OK.  Here’s a log:

[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)

If we accept delivery as we did here where they disconnect before we send 250 
OK, the message gets delivered to our end user.  But the end user sometimes 
gets duplicate messages, sometimes many duplicate messages.  If we don’t accept 
messages from clients that stay connected until the 250 OK is given, no bell.ca 
emails get through.

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

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Bastian Blank via mailop]

On Tue, Mar 07, 2023 at 06:54:31PM +0100, Bastian Blank via mailop wrote:
> What are you doing?  Please show a session transcript if you think there
> are SMTP protocol problems.

Okay, he seems to be mercury.net.

| ;; ANSWER SECTION:
| mercury.net. 2975 IN MX 10 mail.mercury.net.
| mercury.net. 2975 IN MX 20 mail.lsol.net.

Let's see what mail.mercury.net is.

| $ nc mail.mercury.net. 25
| 220 mail.mercury.net
| ehlo test


Okay, while correct, it does only accept CRLF.  Almost all servers
accept bare LF.

| $ nc mail.mercury.net. 25 -C
| 220 mail.mercury.net
| ehlo test
| 250-mail.mercury.net Hello [x.x.x.x]
| 250-SIZE 69905066
| 250-AUTH LOGIN CRAM-MD5
| 250-STARTTLS
| 250-8BITMIME
| 250-DSN
| 250 OK
| mail from:<>
| 554 Sending address not accepted due to spam filter
| mail from:


- No ESMTP marker.
- Can anyone point me to the RFC for the SMTP extension "OK"?
- Rejects empty from.
- Yes, t...@test.de is no existing address.

Bastian

-- 
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
   stardate 3468.1.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Bastian Blank via mailop]

Hi David

On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:
> I’m trying to reach someone at bell.ca  who can help us with 
> two inter-related issues.

Why do you link to http://bell.ca/?  Or is that some unhelpful client
again?

> 1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, our 
> users cannot receive any bell.ca  mail.

SMTP servers don't send e-mail, they receive e-mail.  You mean SMTP
client.  However an e-mail transaction ends with ..  So at
the time QUIT would be sent, no e-mail transaction is running.

> 2.  If we accept without a QUIT, our users occasionally get duplicate 
> messages and sometimes LOTS of duplicate messages.

What are you doing?  Please show a session transcript if you think there
are SMTP protocol problems.

Bastian

-- 
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Bell.ca servers disconnecting before QUIT

[David Sovereen via mailop]

Hello,

I’m trying to reach someone at bell.ca  who can help us with 
two inter-related issues.

1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, our 
users cannot receive any bell.ca  mail.

2.  If we accept without a QUIT, our users occasionally get duplicate messages 
and sometimes LOTS of duplicate messages.

Is anyone else seeing this issue?

If someone from bell.ca  is out there, I’d appreciate an email 
off-line.

Thanks,

Dave

David Sovereen
 
Mercury Network Corporation
2719 Ashman Street, Midland, MI 48640
989.837.3790 x151 office | 888.866.4638 toll free | 989.837.3780 fax
 
Telephone  |  Internet  |  Hosting
 
david.sover...@mercury.net 
www.mercury.net 


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

[mailop] bell.ca/bell.net contact?

[Erwin via mailop]

Hello,

We appear to be hitting a capacity wall from one of our ranges (
15.222.16.128/25) in delivering to their servers at 184.150.200.82 and
184.150.200.210.

I reached out to postmas...@bell.ca (postmas...@bell.net bounced) at the
end of yesterday (PDT) but no response yet, so maybe here?

Sincerely,
Erwin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] bell.ca/bell.net contact?

[Erwin Harte via mailop]

On 10/23/20 11:04 AM, Erwin Harte wrote:

Hello,

We appear to be hitting a capacity ceiling from one of our ranges 
(15.222.16.128/25) in delivering to their servers at 184.150.200.82 
(smtpvipmtrlin.bell.net/mxmta.owm.bell.net) and 184.150.200.210 
(smtpviptorin.bell.net/mxmta.owm.bell.net).


I reached out to postmas...@bell.ca (postmas...@bell.net bounced, 
alas) at the end of yesterday afternoon (PDT) but no response yet, so 
maybe someone here can put me in touch with them, or suggest a way?


A suggestion I received off-list was ispsupp...@bell.ca but that address 
doesn't seem to exist at this time.


: host mx-wyn.bell.ca[67.69.243.161] said: 550 #5.1.0
    Address rejected. (in reply to RCPT TO command)

Thanks,
Erwin

===
Get the 13 Email Threat Types eBook

https://www.barracuda.com/13-threats-report?utm_source=email_signature&utm_campaign=13tt&utm_medium=email&utm_content=13tt-ebook

DISCLAIMER:
This e-mail and any attachments to it contain confidential and proprietary 
material of Barracuda, its affiliates or agents, and is solely for the use of 
the intended recipient. Any review, use, disclosure, distribution or copying of 
this transmittal is prohibited except by or on behalf of the intended 
recipient. If you have received this transmittal in error, please notify the 
sender and destroy this e-mail and any attachments and all copies, whether 
electronic or printed.
===
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] bell.ca/bell.net contact?

[Erwin Harte via mailop]

Hello,

We appear to be hitting a capacity ceiling from one of our ranges 
(15.222.16.128/25) in delivering to their servers at 184.150.200.82 
(smtpvipmtrlin.bell.net/mxmta.owm.bell.net) and 184.150.200.210 
(smtpviptorin.bell.net/mxmta.owm.bell.net).


I reached out to postmas...@bell.ca (postmas...@bell.net bounced, alas) 
at the end of yesterday afternoon (PDT) but no response yet, so maybe 
someone here can put me in touch with them, or suggest a way?


Thanks in advance,
Erwin

===
Get the 13 Email Threat Types eBook

https://www.barracuda.com/13-threats-report?utm_source=email_signature&utm_campaign=13tt&utm_medium=email&utm_content=13tt-ebook

DISCLAIMER:
This e-mail and any attachments to it contain confidential and proprietary 
material of Barracuda, its affiliates or agents, and is solely for the use of 
the intended recipient. Any review, use, disclosure, distribution or copying of 
this transmittal is prohibited except by or on behalf of the intended 
recipient. If you have received this transmittal in error, please notify the 
sender and destroy this e-mail and any attachments and all copies, whether 
electronic or printed.
===
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] bell.ca?

[Matt Vernhout via mailop]

Just in case I passed this along to one of my contacts at Bell... not sure if 
they are represented here or not. 

Cheers,

~
Matt

> On Jan 16, 2020, at 18:21, Steven Champeon via mailop  
> wrote:
> 

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] bell.ca?

[rps462 via mailop]

An accident, I'm sure. I forwarded this to them, thanks!
-Ryan

On Thu, Jan 16, 2020 at 4:22 PM Steven Champeon via mailop <
mailop@mailop.org> wrote:

>
> Is anyone from bell.ca here who has any way to fix their DNS? They seem
> to have several blocks that have spaces (\032) in their PTRs, which is
> sort of weird.
>
> eg:
>
> 74.15.212.103:bras-base-sjerpq0524w-grc-12  -74-15-212-103.dsl.bell.ca
>
> I mean, your network your rules, but this just seems like an accident.
>
> --
> hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w:
> http://hesketh.com/
> Internet security and antispam hostname intelligence:
> http://enemieslist.com/
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] bell.ca?

[Steven Champeon via mailop]

Is anyone from bell.ca here who has any way to fix their DNS? They seem
to have several blocks that have spaces (\032) in their PTRs, which is
sort of weird.

eg:

74.15.212.103:bras-base-sjerpq0524w-grc-12  -74-15-212-103.dsl.bell.ca

I mean, your network your rules, but this just seems like an accident.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/
Internet security and antispam hostname intelligence: http://enemieslist.com/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop