googlemail-delivery-system sucks ...
Betz.W...@googlemail.com
the delivery-system of googlemail sucks under particular circumstance:
Each time I send mails to the servers of my university I get the
following message back (the server is 'ohm-hochschule.de'):
This is an automatically generated Delivery Status Notification
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipient has been delayed:
...
and after some days:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
...
The problem is caused by following circumstances:
- The google-server sends the mail to '...@ohm-hochschule.de'
- The university-server will block the first mailing.
- google will resend the mail ...
... there are two possibilities:
- First possibility (the uncommon exceptional case):
The 'resend'-server is the server which sent the mail the first time.
--> There will be no problem in delivering the mail.
- Second (the likely) possibility:
The 'resend'-server is not the server which sent the mail the first
time.
--> the googlemail-delivery-system sucks ...
Because of that the university recommends not to use googlemail.
This is really bad, since mails send to my university-server are my
top-priority-mails I could not afford to be lost transmission.
Wolfgang
Zack (Doc)
Google's fault?
I'm gathering the reason this is "a bad way" is because Google is
using multiple servers to send out mail. This is actually a standard
practice, and not limited to Google. If this is a problem for the
university, they need to rethink their systems.
I checked out the university web page and while I understand precious
little German, I did see several references to googlemail.com e-mail
addresses. Faculty and Staff both using them and publishing them as
their address. For this reason, I suspect the "recommends not to use
googlemail" is far from a universal precept.
Also... at no point are the e-mails ever "lost", they just don't get
delivered. Sounds like the university needs to research the use of
domain-keys and SPF records for determining who they will accept mail
from.
On Jan 19, 2008 11:16 AM, Betz.W...@googlemail.com
Betz.W...@googlemail.com
but I have had a conversation with a guy from the data centre of my
university. He said they do not intend to change the system. He said
that is is aware of the issue of the use multiple servers - and
suggested to forbear from providers using them (googlemail, gmx).
The used system is to refuse the first mail and to remember the
address of the sending server ...
Is it not possible that the server which originally was sending the
mail will also handle the resend?
The mails are not lost, that's true - but you can not rely on them if
you are counting on a answer or if you need an information to be
transmitted ... so from some point of view they are lost (at least for
the addressee).
On 19 Jan., 18:17, "Zack (Doc)" <z...@tnan.net> wrote:
> If the university server is blocking the first connection, why is this
> Google's fault?
>
> I'm gathering the reason this is "a bad way" is because Google is
> using multiple servers to send out mail. This is actually a standard
> practice, and not limited to Google. If this is a problem for the
> university, they need to rethink their systems.
>
> I checked out the university web page and while I understand precious
> little German, I did see several references to googlemail.com e-mail
> addresses. Faculty and Staff both using them and publishing them as
> their address. For this reason, I suspect the "recommends not to use
> googlemail" is far from a universal precept.
>
> Also... at no point are the e-mails ever "lost", they just don't get
> delivered. Sounds like the university needs to research the use of
> domain-keys and SPF records for determining who they will accept mail
> from.
>
Zack (Doc)
that's just patently stupid.
A... Google is far from the only provider using multiple servers...
AOL does, most ISPs do; and EVERY free mail service does simply
because of their size.
The number of particular servers a system uses will vary depending on
the size of their customer base, but having only 1 is a recipe for
disaster. My ISP might only have 3, so there's a 33% chance the
second attempt will come from the same server, but someone like Google
has probably 30, so there's only a 3.3% chance.
Now... lets go a step further... there are NEVER just 2 attempts. As
your first bounce message was telling you, the servers will continue
to try every 4 hours for 5 days... that's 30 attempts. If there are
less than 30 servers in the queue, at least one will be repeated near
the end, but that requires the receiver to remember EACH attempt and
compare against all others. If they only compare to the very last
attempt, the odds never increase.
If they insist on this type of system, they should at least develop a
trusted host list. This would consist of hosts and systems that have
a) previously passed their little test, or b) have demonstrated a spam
presentation rate of under 10%. They wouldn't even have to develop
their own list as there are dozens of lists out there already
performing that function across the net.
If their intent is to cut down on spam (that's usually why this is
done), then the first step is to do this only for open-relays, or just
refuse acceptance from open-relays. Something like 90% of the spam on
the net is propogated through open-relays. This is done to hide the
spammers' true identity. Their method is generally very good for
open-relay/spam stopping, but a major pain if applied universally.
If a business did exactly what your school is doing... they'd be out
of business. It's too restrictive, and has NO intelligence built into
it. You have to think about these things before deploying them. This
sounds like it was not fully thought out.
Definitely the schools problem, and if it's not brought to their
attention, they'll just let it get worse till it hurts professional
relationships. Microsoft has more servers than Google. I guess they
can't get their patch e-mails to keep the servers running.
On Jan 19, 2008 1:30 PM, Betz.W...@googlemail.com
Betz.W...@googlemail.com
hochschule.de' is the only systems I have experienced so far which
can't cope with googlemail.
I'll try to get in contact with the person responsible for that ...
... and still there is the final eventuality to use the internal
system for that kind of conversation ... but that would be a filthy
solution cause I'm really fond of the google-service.
On 19 Jan., 20:38, "Zack (Doc)" <z...@tnan.net> wrote:
> I'm sorry, but I've worked in data centers most of my adult life, and
> that's just patently stupid.
>
> A... Google is far from the only provider using multiple servers...
> AOL does, most ISPs do; and EVERY free mail service does simply
> because of their size.
>
> The number of particular servers a system uses will vary depending on
> the size of their customer base, but having only 1 is a recipe for
> disaster. My ISP might only have 3, so there's a 33% chance the
> second attempt will come from the same server, but someone like Google
> has probably 30, so there's only a 3.3% chance.
>
> Now... lets go a step further... there are NEVER just 2 attempts. As
> your first bounce message was telling you, the servers will continue
> to try every 4 hours for 5 days... that's 30 attempts. If there are
> less than 30 servers in the queue, at least one will be repeated near
> the end, but that requires the receiver to remember EACH attempt and
> compare against all others. If they only compare to the very last
> attempt, the odds never increase.
>
> If they insist on this type of system, they should at least develop a
> trusted host list. This would consist of hosts and systems that have
> a) previously passed their little test, or b) have demonstrated a spam
> performing that function across the net.
>
> If their intent is to cut down on spam (that's usually why this is
> done), then the first step is to do this only for open-relays, or just
> refuse acceptance from open-relays. Something like 90% of the spam on
> the net is propogated through open-relays. This is done to hide the
> spammers' true identity. Their method is generally very good for
> open-relay/spam stopping, but a major pain if applied universally.
>
> If a business did exactly what your school is doing... they'd be out
> of business. It's too restrictive, and has NO intelligence built into
> it. You have to think about these things before deploying them. This
> sounds like it was not fully thought out.
>
> Definitely the schools problem, and if it's not brought to their
> attention, they'll just let it get worse till it hurts professional
> relationships. Microsoft has more servers than Google. I guess they
> can't get their patch e-mails to keep the servers running.
>
Betz.W...@googlemail.com
1. That 90f% of the spam on the net is propogated through open-relays
is obsolete - this value was up to date twelve years ago when all
relays were open. Spam mails have been sent almost exclusively by 'bot-
networks' for about five years now. The few open-relays left are
virtually irrelevant.
2. As a matter of principle the number of mailservers doesn't matter -
as far as they adhere to the current RFCs. This implies that THE
sending server of a mail tries to deliver the mail until he was able
to deliver or three days are over. And that is the point google is not
conform to the RFC - by google the server next to try has not
obligatorily to be the originally sending server. (the greylisting
timeout of the university-system is 4 hours)
3. Furthermore you can't whitelist googlemail because google can not
assure that their addresses are counterfeit - otherwise you could
reason that google self runs a 'bot-network'.
... why is google not conform to the RFC ???
On 19 Jan., 21:29, "Betz.Wolfg...@googlemail.com"
bkennelly
address to be used for retries.
Your university's scheme is clever, but it is flawed.
On Jan 22, 9:51 am, "Betz.Wolfg...@googlemail.com"
> Today I got a message from my university - I'll try to summarize it:
>
>
> as far as they adhere to the current RFCs. This implies that THE
> sending server of a mail tries to deliver the mail until he was able
> to deliver or three days are over. And that is the point google is not
> conform to the RFC - by google the server next to try has not
> obligatorily to be the originally sending server. (the greylisting
> timeout of the university-system is 4 hours)
>
>
Zack (Doc)
1. The way bot-networks function is by creating open-relays, so it's
still basically a true statement, just the specifics of HOW it's done
have "advanced to a new level".
2. I can find nothing in RFC2821 that indicates it should be the same
server that reattempts.
3. I don't know that that means... Google uses domain-keys and signs
all the mail and maintains SPF records. Their mail server list is a
matter of public fact, and that can be verified. What is meant by
"can not assure that their addresses are counterfeit"? You mean that
the account that's sending is not verified? You mean that the
university can't verify that it's actually receiving from Google's
authorized servers?
On Jan 22, 2008 11:51 AM, Betz.W...@googlemail.com