Any Comcast Limit on # of Email Addresses Sending an Email?

[posterboy]

We're sending an email invite to art gallery show. Does Comcast have
any limit like 50 addresses or any large number as to how many addresses
are used in the BCC field or if Comcast rejects the email from being
send if too many are used?

John
--
This is not an email so the anti-virus software hasn't wasted your time
telling you that this note was checked for viruses, because this is
USENET for crying out loud

[Allodoxaphobia]

On Sun, 27 Mar 2016 19:38:15 -0400, posterboy wrote:
> We're sending an email invite to art gallery show. Does Comcast have
> any limit like 50 addresses or any large number as to how many addresses
> are used in the BCC field or if Comcast rejects the email from being
> send if too many are used?

Well, what happens when you test it?

[Adam H. Kerman]

posterboy <jo...@john.com> wrote:

>We're sending an email invite to art gallery show. Does Comcast have
>any limit like 50 addresses or any large number as to how many addresses
>are used in the BCC field or if Comcast rejects the email from being
>send if too many are used?

>John

I have no idea. It's a lousy idea not to use a mailing list server. You
should ask your contacts for permission to contact them by email (a
checkbox on a form will do) or to subscribe. Some Mail servers that serve
your recipient's mailboxes will flag it as spam.

Send the messages individually with the recipient on To, particularly to
those that have given you Yahoo addresses, Hotmail and various Microsoft
addresses, and various AT&T addresses.

[Barry Margolin]

In article <nd9qn5$4i6$1...@dont-email.me>, posterboy <jo...@john.com>
wrote:

> We're sending an email invite to art gallery show. Does Comcast have
> any limit like 50 addresses or any large number as to how many addresses
> are used in the BCC field or if Comcast rejects the email from being
> send if too many are used?

Found by googling "comcast email address limit":

http://customer.xfinity.com/help-and-support/internet/limitations-on-send
ing-email/

An email message can be sent to a maximum of 100 recipients. Any
messages sent to over 100 recipients will not be delivered.

XFINITY customers can email up to 1,000 recipients per day. If an
account exceeds the 1,000-recipient limit, the account will not be able
to send for the remainder of the day.

The maximum size of an email cannot exceed 25 MB; this includes
attachments, headers, text, formatting, etc.

--
Barry Margolin
Arlington, MA

[posterboy]

Thanks for that reply - didn't even think to Google that - weird! And
it wouldn't make any sense to test it like one suggested, for obvious
reasons!

[Pussy Galore]

On 03/29/2016 05:50 PM, posterboy wrote:

Thanks for that reply - didn't even think to Google that - weird!  And it wouldn't make any sense to test it like one suggested, for obvious reasons!

The proof of the pudding is in the eating, YMMV.   Let us know how the first "test" goes.

[meagain]

On 3/29/2016 7:50 PM, posterboy wrote:
> On Mon, 3/28/2016 11:40 AM, Barry Margolin wrote:
>> In article <nd9qn5$4i6$1...@dont-email.me>, posterboy <jo...@john.com>
>> wrote:
>>
>>> We're sending an email invite to art gallery show. Does Comcast have
>>> any limit like 50 addresses or any large number as to how many addresses
>>> are used in the BCC field or if Comcast rejects the email from being
>>> send if too many are used?
>>
>> Found by googling "comcast email address limit":
>>
>> http://customer.xfinity.com/help-and-support/internet/limitations-on-send
>> ing-email/
>>
>> An email message can be sent to a maximum of 100 recipients. Any
>> messages sent to over 100 recipients will not be delivered.
>>
>> XFINITY customers can email up to 1,000 recipients per day. If an
>> account exceeds the 1,000-recipient limit, the account will not be able
>> to send for the remainder of the day.
>>
>> The maximum size of an email cannot exceed 25 MB; this includes
>> attachments, headers, text, formatting, etc.
>>
> Thanks for that reply - didn't even think to Google that - weird! And
> it wouldn't make any sense to test it like one suggested, for obvious
> reasons!
>

Some email recipients in other domains have in the past reported not
being able to receive large emails from comcast.net.

[Barry Margolin]

In article <ndgtoj$447$1...@dont-email.me>,

Just because Comcast allows mail up to 25 MB it doesn't mean that the
recipient's server allows it. The actual size limit is the minimum of
the two sites' limits.

[Adam H. Kerman]

This is why ghod invented ftp. Large file transfer as an email attachment
is an outrageous idea.

[Barry Margolin]

In article <tnfofbpii5snvakr9...@4ax.com>,
Bill <no...@none.invalid> wrote:

> On Wed, 30 Mar 2016 17:00:39 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com>
> wrote:

>
> >meagain <rick0....@gmail.com.spamless> wrote:
> >>Some email recipients in other domains have in the past reported not
> >>being able to receive large emails from comcast.net.
> >
> >This is why ghod invented ftp. Large file transfer as an email attachment
> >is an outrageous idea.
>

> In my experience, FTP seems to have all but disappeared in recent years. A
> tiny bit of it has been replaced by SFTP and FTPS, but mostly it's been
> replaced by HTTPS, as in web-based Dropbox-like applications.

Yeah. Before DropBox and Google Drive, there was yousendit.com, where
you could upload a large file and send a link to it in an email.

[Adam H. Kerman]

Bill <no...@none.invalid> wrote:
>30 Mar 2016 17:00:39 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>meagain <rick0....@gmail.com.spamless> wrote:

>>>Some email recipients in other domains have in the past reported not
>>>being able to receive large emails from comcast.net.

>>This is why ghod invented ftp. Large file transfer as an email attachment
>>is an outrageous idea.

>In my experience, FTP seems to have all but disappeared in recent years. A
>tiny bit of it has been replaced by SFTP and FTPS,

Yes, I use sftp frequently. Only one site I use hasn't implemented ssh.

>but mostly it's been replaced by HTTPS, as in web-based Dropbox-like
>applications.

Isn't that literally calling ftp within the secured connection, or
something like that? All browsers are ftp/sftp clients.

[Bob (not my real pseudonym)]

On Wed, 30 Mar 2016 23:34:34 -0500, Bill <no...@none.invalid> wrote:

>On Thu, 31 Mar 2016 03:20:21 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com>

>wrote:
>
>>Bill <no...@none.invalid> wrote:
>>>30 Mar 2016 17:00:39 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>>>meagain <rick0....@gmail.com.spamless> wrote:
>>
>>>>>Some email recipients in other domains have in the past reported not
>>>>>being able to receive large emails from comcast.net.
>>
>>>>This is why ghod invented ftp. Large file transfer as an email attachment
>>>>is an outrageous idea.
>>
>>>In my experience, FTP seems to have all but disappeared in recent years. A
>>>tiny bit of it has been replaced by SFTP and FTPS,
>>
>>Yes, I use sftp frequently. Only one site I use hasn't implemented ssh.
>>
>>>but mostly it's been replaced by HTTPS, as in web-based Dropbox-like
>>>applications.
>>
>>Isn't that literally calling ftp within the secured connection, or
>>something like that?
>

>No, HTTPS. Unlike FTP, HTTPS encrypts the credentials, if I understand
>correctly, so it's more secure than FTP.

>
>>All browsers are ftp/sftp clients.
>

>FTP, yes, but I didn't know that browsers could do SFTP, which appears to be
>a variation of SSH. I use WinSCP for SFTP and Putty for SSH.

If one reads the last few sentences with Robin Williams (Good Morning
Viet Nam) voice, one gets a chuckle. Then a sigh.

https://www.youtube.com/watch?v=wXlvy3sTTBk

Sorry for butting in...

[meagain]

Excellent! You can buttin anytime!

[Adam H. Kerman]

Bill <no...@none.invalid> wrote:

>No, HTTPS. Unlike FTP, HTTPS encrypts the credentials, if I understand
>correctly, so it's more secure than FTP.

I'm not talking about encrypting the credentials. I'm talking about the
file transfer, which takes place in an encrypted layer, either TLS or SSL,
as established by HTTPS. This is my limited understanding of what's taking
place, that once the encrypted communications layer has been established,
files are retrieved with FTP commands.

>>All browsers are ftp/sftp clients.

I'm wrong. Firefox isn't an sftp client; just tried it.

[Adam H. Kerman]

Bill <no...@none.invalid> wrote:

>31 Mar 2016 13:01:46 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>Bill <no...@none.invalid> wrote:
>>>31 Mar 2016 03:20:21 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>>>Bill <no...@none.invalid> wrote:
>>>>>30 Mar 2016 17:00:39 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>>>>>meagain <rick0....@gmail.com.spamless> wrote:

>>>>>>>Some email recipients in other domains have in the past reported not
>>>>>>>being able to receive large emails from comcast.net.

>>>>>>This is why ghod invented ftp. Large file transfer as an email attachment
>>>>>>is an outrageous idea.

>>>>>In my experience, FTP seems to have all but disappeared in recent years. A
>>>>>tiny bit of it has been replaced by SFTP and FTPS,

>>>>Yes, I use sftp frequently. Only one site I use hasn't implemented ssh.

>>>>>but mostly it's been replaced by HTTPS, as in web-based Dropbox-like
>>>>>applications.

>>>>Isn't that literally calling ftp within the secured connection, or
>>>>something like that?

>>>No, HTTPS. Unlike FTP, HTTPS encrypts the credentials, if I understand
>>>correctly, so it's more secure than FTP.

>>I'm not talking about encrypting the credentials. I'm talking about the
>>file transfer, which takes place in an encrypted layer, either TLS or SSL,
>>as established by HTTPS. This is my limited understanding of what's taking
>>place, that once the encrypted communications layer has been established,
>>files are retrieved with FTP commands.

>No, a transfer initiated via HTTPS (or HTTP) stays with that protocol during
>the transfer. The browser doesn't silently switch to FTP.

You tell me, then. In the secured session, what is the command the
client (browser) sends to obtain a file? It's not "get"?

>>>>All browsers are ftp/sftp clients.

>>I'm wrong. Firefox isn't an sftp client; just tried it.

>Agreed, I don't think any browsers can do SFTP. Interestingly, SFTP has
>almost nothing in common with FTP, though they share similarities in name
>and purpose.

From this user's perspective, I'm using exactly the same commands
in the interactive and scripted sessions. When ssh stuff was introduced,
there wasn't much of a learning curve.

[Adam H. Kerman]

Bill <no...@none.invalid> wrote:

>31 Mar 2016 21:54:37 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>Bill <no...@none.invalid> wrote:
>>>31 Mar 2016 13:01:46 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
>>>>>31 Mar 2016 03:20:21 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:

>There's no FTP involved there. It's all HTTP.

Thank you for explaining. I thought it was similar.

>>>>>>All browsers are ftp/sftp clients.

>>>>I'm wrong. Firefox isn't an sftp client; just tried it.

>>>Agreed, I don't think any browsers can do SFTP. Interestingly, SFTP has
>>>almost nothing in common with FTP, though they share similarities in name
>>>and purpose.

>>From this user's perspective, I'm using exactly the same commands
>>in the interactive and scripted sessions. When ssh stuff was introduced,
>>there wasn't much of a learning curve.

>No idea what your interactive and scripted sessions might refer to, but SFTP
>is actually SSH, while FTP is a completely different protocol. That's all I
>was trying to say.

When I use sftp, it invokes an interactive session with its own command
line. Just like ftp, it can be scripted for automated processing.
The commands are the same. I assume they did that to simplify adaptation
of existing ftp scripts to sftp.

[Allodoxaphobia]

On Thu, 31 Mar 2016 15:54:52 -0500, Bill wrote:
>
> Agreed, I don't think any browsers can do SFTP.

Linux's konqueror does sftp. Probably other distro-specific browsers
can, as well. With split-screen in konqueror I have a terrific file
manipulation platform anywhere across the intra/inter-net.

[R. Lynn Rardin]

In article <fd3rfb9kgi0ajdhdd...@4ax.com>,
Bill <no...@none.invalid> wrote:

> On Thu, 31 Mar 2016 13:01:46 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com>

> wrote:
>
> >Bill <no...@none.invalid> wrote:
> >>31 Mar 2016 03:20:21 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
> >>>Bill <no...@none.invalid> wrote:
> >>>>30 Mar 2016 17:00:39 +0000 (UTC), "Adam H. Kerman" <a...@chinet.com> wrote:
> >>>>>meagain <rick0....@gmail.com.spamless> wrote:
> >
> >>>>>>Some email recipients in other domains have in the past reported not
> >>>>>>being able to receive large emails from comcast.net.
> >
> >>>>>This is why ghod invented ftp. Large file transfer as an email attachment
> >>>>>is an outrageous idea.
> >
> >>>>In my experience, FTP seems to have all but disappeared in recent years. A
> >>>>tiny bit of it has been replaced by SFTP and FTPS,
> >
> >>>Yes, I use sftp frequently. Only one site I use hasn't implemented ssh.
> >
> >>>>but mostly it's been replaced by HTTPS, as in web-based Dropbox-like
> >>>>applications.
> >
> >>>Isn't that literally calling ftp within the secured connection, or
> >>>something like that?
> >
> >>No, HTTPS. Unlike FTP, HTTPS encrypts the credentials, if I understand
> >>correctly, so it's more secure than FTP.
> >
> >I'm not talking about encrypting the credentials. I'm talking about the
> >file transfer, which takes place in an encrypted layer, either TLS or SSL,
> >as established by HTTPS. This is my limited understanding of what's taking
> >place, that once the encrypted communications layer has been established,
> >files are retrieved with FTP commands.
>

> No, a transfer initiated via HTTPS (or HTTP) stays with that protocol during
> the transfer. The browser doesn't silently switch to FTP.
>

> >>>All browsers are ftp/sftp clients.
> >
> >I'm wrong. Firefox isn't an sftp client; just tried it.
>

> Agreed, I don't think any browsers can do SFTP. Interestingly, SFTP has
> almost nothing in common with FTP, though they share similarities in name
> and purpose.

Although Firefox doesn't support SFTP or FTPS directly, the FireFTP
add-on (http://fireftp.mozdev.org/) supports these protocols, as well
as FTP.

--

R. Lynn Rardin

[Adam H. Kerman]

R. Lynn Rardin <rar...@brandeis.edu> wrote:

>Although Firefox doesn't support SFTP or FTPS directly, the FireFTP
>add-on (http://fireftp.mozdev.org/) supports these protocols, as well
>as FTP.

Installed; thanks. I knew there'd be an add on.